Изпечатай

[m0rph]

Цитат (spawnman @ Юни 23 2005,22:46)

Що не качиш някъде подобен файл (толкова голям, колкото прецениш) и да се пробваме? Аз вкъщи нямам такова чудо под ръка, докато в офиса Photoshop & Illustrator безпроблемно работят с ~60 МБ-ви файлове на 256 МБ памет. Уловката е, че не е ограничена големината на виртуалната памет.

http://store2.data.bg/stoeneca/secretmaps/bg-i/3977-4.jpg  Това са топографски карти. Сега да направя малко уточнение.
1) Под Windows се отварят защото Irfan View се вмества в РАМ паметта тоест заема по около 120МБ на карта
2) Под Линукс намерих няколко програми които да го отварят (GKView, XNView).
3) KuickShow за същата карта под Линукс се опитва да заеме повече памет отколкото имам (Суап + Рам) и се стига до там, че даже мишката не може да се мърда.
Както vic_semionov е казал ми се струва че проблема си е в Линукс.
Колкото до РАМ модулите на следните адреси са снимки на двата модула.
http://www.free.bol.bg/m0rph/Untitled-1.jpg
http://www.free.bol.bg/m0rph/Untitled-2.jpg
Когато са сами, тоест съм поставил само единият от двата всичко си работи добре, може и с месеци да не получа някаква грешка под Win, докато като поставя и двата след седмица вече Win-a e за преинсталация а Линукс-а се прецака още на първото пускане.

[CaBA]

Цитат

А това че системата е проектирана да използва максимално свободната памет няма нищо общо в случая. Цялата свободна памет се използва само за дискови буфери, т.е. кеш. Тези буфери се заделят от ядрото, не от userland процесите, и се заделят само в RAM, никога в swap. И при недостиг на RAM въпросните буфери се записват обратно на диска (ако се налага) и се освобождават. Само това се има предвид под "максимална употреба на свободната памет". Иначе по правило колкото по-малко памет ползва една програма, толкова по-добре.

Имах предвид, че повечето (разбирай - почти всички) потребителски програми са написани да използват максимално агресивно паметта. Ричард Столман казва следното по въпроса: "In programs for which handling very large files was not crucial, we encouraged programmers to read an entire input file into core, then scan its contents without having to worry about I/O.These decisions enabled many GNU programs to surpass their Unix counterparts in reliability and speed." [Ние окуражавахме програмистите да изчитат целия входен файл за програми, където поддръжката на много големи файлове не е критична, и след това да работят с него без да се притeсняват за входно-изходните операции. Тези решения направиха програмите на GNU по-бързи и по-надеждни от конкурентните им в Unix. ]

Това, че ядрото се стреми да използва максимално свободната памет е просто следствие на горния принцип. Разбира се, "много голям файл" е променливо понятие - по времето, когато се е изказал Столмън, 1МБ дисково пространство е смятано за огромен обем.

[vic_semionov]

Цитат (CaBA @ Юни 24 2005,18:15)

Имах предвид, че повечето (разбирай - почти всички) потребителски програми са написани да използват максимално агресивно паметта. Ричард Столман казва следното по въпроса: "In programs for which handling very large files was not crucial, we encouraged programmers to read an entire input file into core, then scan its contents without having to worry about I/O.These decisions enabled many GNU programs to surpass their Unix counterparts in reliability and speed." Това, че ядрото се стреми да използва максимално свободната памет е просто следствие на горния принцип. Разбира се, "много голям файл" е променливо понятие - по времето, когато се е изказал Столмън, 1МБ дисково пространство е смятано за огромен обем.

Разбирам. Със Столман не мога да споря '>

[spawnman]

Е щом qiv не се справи...

[rpetrov]

Цитат (m0rph @ Юни 24 2005,15:16)

.../3977-4.jpg ...

безпроблемно се зарежда за около 15 сек. при KDE 3.1, 128 MB RAM, 128 MB swap ...

[eNcLaVe]

Аз пък искам да кажа че имам 256 МБ РАМ и 520 МБ суап. Станно, но факт е, че суап-а ми никога ама никога не се ползва !!! винаги стои 100% свободен дори когато цялата налична РАМ се изчерпа. А съм я изчерпвал със един куп Konqueror браузъри заредени с бая тежки сайтове, конзола, няколко снимки през kuickshow и XMMS. Просто когато РАМ-а се напълни до дупка, средата "лекичко" спича за 3-4 секунди и после просто последния процес/програма си заминава самичко ! след това всичко си е наред. незнам защо суап-а не се използва ?? макар че си имам дял, форматиран като линукс суап и зададен като такъв при инсталацията на линукса......

[rpetrov]

Цитат (eNcLaVe @ Юни 27 2005,20:50)

Аз пък искам да кажа че имам 256 МБ РАМ и 520 МБ суап. Станно, но факт е, че суап-а ми никога ама никога не се ползва !!! винаги стои 100% свободен дори когато цялата налична РАМ се изчерпа...

провери дали swap-а е наличен с

Примерен код

/sbin/swapon -s

еквивалентно на

Примерен код

cat /proc/swaps

[luda_glawa]

Малко късно ама ...

Значи машината е: PIII 600, 160MBRAM, 160MB swap. При 100MB RAM и 160MB swap свободни опитах да отворя картинката която си дал. Трагедия. Зае цялата свободна памет и се започна с цикленето. Така, че проблема е изцяло софтуерен.

P.S. Отворих картинката с GQView (или поне се опитах  '> )

[alabal]

Цитат

Така, че проблема е изцяло софтуерен.

Братко, а на таз машина проверил ли си й паметта?

Файла го свалих , отворих го без проблем.Без да ми забива мишка ...
Даже ми остана 33Мв свободна RAM.
____
1.7GHz , 256MB RAM, 512Mb Swap , SuSe 9.3 , Kernel 2.6.11.

[luda_glawa]

Цитат (alabal @ Юни 29 2005,00:18)

Цитат Така, че проблема е изцяло софтуерен. Братко, а на таз машина проверил ли си й паметта?

Хапсолютно работи. Гледам GKRealm-a как намалява свободнара памет до 0МБ и тогава се получава. Свободната RAM става 9МБ а суап файла става 0МБ свободни. Иначе до този момент всичко работи на "шест" както се казва. Интересно ми е колко е голям в неархивиран вид. BMP примерно.

[plamen_t]

Ами на мене файлът ми се отваря с Konqueror за около 3-4 секунди и с Kuickshow за горе-долу същото време. Като се опитах обаче през Gimp-a и нещо много зацикли и не ми се чакаше да го отвори и след около 1 минута зареждане го убих.

Системата ми е Slackware-current, AMD Sempron 1667 MHz, 256 RAM, 512 Swap, KDE 3.4.1

[luda_glawa]

Цитат (plamen_t @ Юни 29 2005,22:45)

Ами на мене файлът ми се отваря с Konqueror за около 3-4 секунди и с Kuickshow за горе-долу същото време. Като се опитах обаче през Gimp-a и нещо много зацикли и не ми се чакаше да го отвори и след около 1 минута зареждане го убих. Системата ми е Slackware-current, AMD Sempron 1667 MHz, 256 RAM, 512 Swap, KDE 3.4.1

Става ли да видиш през Konqueror-a колко рам заема и съответно през GIMP. Просто за статистиката. Моята машина не можеш да я сравняваш с твоята :-).

[m0rph]

на мене картинката под Win с IrfanView ми заема 120 МБ памет, а под Lin с KuickShow така и не разбрах обаче със сигурност минава 200 МБ защото не ми остава нищо свободно. Вероятно KuickShow я разкомпресирва веднъж от jpg-то в паметта а после се опитва да я копира втори път в паметта за да я покаже на екрана. До този извод стигнах, защото след като се заемат около 120 МБ (колкото е разкомпресирана) се появява прозореца където трябва да се покаже, но той остава черен, а програмата се опитва да заеме още бог знае колко МБ при което паметта ми свършва и почва да цикли.

[plamen_t]

С Gimp-a ми зае малко над 300 МВ и трябваше да чакам около 3 минути да зареди файлът и после забелязах, че за всяко скролиране или местене на прозореца с изображението отиват още по  10-15 секунди '>
Konqueror-a ми зае от swap-a. Горе-долу около 70 МВ. Толкова приблизително зае и с Kuickshow-a. При тях обаче скролирането, zoom-a и останалите неща се извършват почти веднага за разлика от Gimp-a.
Явно Gimp-a не става за обработка на големи файлове.