Изпечатай

[loxs]

Здравейте, не намерих нищо с търсачката за проблема си, а не знам как точно да го формулирам за да търся в чичо Гугъл.
Проблемът ми е следният:
Слак 10.2, 256 РАМ, 512 суап
Чета едни огромни медицински .pdf-и. Като казвам "огромни", имам предвид файлове с размери по 100-200 мегабайта (че и повече).
Знам, че машинката ми е слабичка, но тя някак си се оправя с четенето на един файл. Проблемът идва след като затворя първия и отворя накой друг (не отварям два едновременно, защото се пълнят рам+суап '>).
След като съм затворил първия, суапа още си е наполовина пълен от него и втория го донапълва.
Въпросът ми е дали може след като затворя първия файл, с някаква команда да си "опразня" суапа, така, че той да е празен като отворя втория файл.
Знам, че ще ме посъветвате да си угплемя суап-а. И това ще стане, но точно в момента нямам възможност да го направя...

[melwin]

swapoff -a
swapon -a

[loxs]

Хмм, тази процедура ми направи следните неща:
1. Всичко от суапа не се изтрива, а отива в рам-а и системата зависва за няколко минути.
2. Утрепа ми половината програми, които вървяха
3. Като цяло отне няколко минути... време доста повече от необходимото за рестартиране на графичната среда... което практикувам по необходимост до сега....

[Izzy]

sync не беше ли точно за това ?

Цитат

sync - flush filesystem buffers

[loxs]

Ами току що прочетох мауала на командата (който е доста кратичък) и не ми изглежда да прави това:

Цитат

`sync': Synchronize data on disk with memory ============================================    `sync' writes any data buffered in memory out to disk.  This can include (but is not limited to) modified superblocks, modified inodes, and delayed reads and writes.  This must be implemented by the kernel; The `sync' program does nothing but exercise the `sync' system call.    The kernel keeps data in memory to avoid doing (relatively slow) disk reads and writes.  This improves performance, but if the computer crashes, data may be lost or the filesystem corrupted as a result. `sync' ensures everything in memory is written to disk.    Any arguments are ignored, except for a lone `--help' or `--version' (*note Common options:.    An exit status of zero indicates success, and a nonzero value indicates failure.

И все пак пробвах, но нямаше ефект. Заетостта на суап-а не се промени

[melwin]

Ами пробвай с :
dd if=/dev/zero of=/dev/$swap_device bs=1024 count=524280

[laskov]

Мисля, че правилното име на темата вече е "Как да си крашна системата?"

[loxs]

Абе така си е, ама съм навит да я крашна 5-6-найсе пъти, ако стане далаверата с опразването на суап-а '>

[melwin]

Помогна ли писането на нули?

едит:Ако не е .. освен следното, друго не се сещам:
swapoff -a
mkswap /dev/$swap_dev
swapon -a

[loxs]

Ами да, крашна се системата '>
След като написах командата с

Примерен код

dd if=/dev/zero of=/dev/hda2 bs=1024 count=524280

 опитах в друг терминал да видя с top потреблението на ресурси..
Отговорът беше нещо от сорта на:

Init : Panick : Segentation enforcement <nqkakvi cifri> <i oshte neshto>

A графичнта среда продължи да работи още около минута... след което си замина.

Но трябва да призная... това все пак си беше най-ефективния начин за опразване на суап-а  

[Hapkoc]

melwin, то проблема според мен е със swapoff, смисъл, че като пуснеш swapoff системата се опитва цялата информация от swap-а да я прехвърли в оперативната памет и това доста бави и вероятно пак оттам идва убиването на програми, понеже не стига памет.

а това с писането на нули ми се струва нечовешки грубо... смисъл все едно да пишеш нули в оперативната памет. ако изобщо е възможно такова нещо не виждам как няма да забие системата...

За какво ти е да празниш суап, това е работа на ядрото, не твоя. Просто си отвори втория пдф след като си затворил първия, айо има нещо ненужно в суап-а, то ще бъде разкарано.

[loxs]

Точно там е работата, че след като затворя първия пи-ди-еф, той остава в суапа...

1. Отварям един пидиеф, после го затварям и отварям нов > системата зависва.
2. Отварям един пидиеф, затварям го и рестартирам КДЕ, след това отварям втория... няма проблеми

Желанието ми е да не се налага това рестартиране на КДЕ.

ПП: Мислех, че проблема се корени в това, че KPDF е интегрирана в КДЕ. Но с XPDF положението е абсолютно същото

[never_mind]

Пробвай с Acrobat reader

Едно глупаво предложение.
Доколкото разбирам има как да се спре използването на виртуална памет. Няма ли начин за бърз формат на дяла?

Пак подчертавам - глупаво предложение.