Linux за българи: Форуми

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

swapoff -a
swapon -a

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

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

Цитат

sync - flush filesystem buffers

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

Цитат

`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.

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

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

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

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

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

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

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

Примерен код

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

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

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

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

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

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

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

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

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

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

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

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

Пробвай с Acrobat reader

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

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

mkswap ?

Аз съм с ядро 2.4.31... пробвах и с мое компилирано и с bare.i, което е ядрото по подразбиране на Слак... но явно ще трябва да се замисля за 2.6 най-накрая

Пробвай след като прочетеш първия файл да затвориш kpdf и се увери ,че е изклюен: #ps | grep kpdf  ,ако не е #kill PID (ID номера на kpdf от предната команда)
Погледни и в temp директорията на kpdf .

Хах, бъзикай се ти

Добре .. по принцип съм съгласен, че не е добра идея да се пишат тези 0-ли. Но по принцип когато суап-а е празен и /dev/swap e празно - от там ми дойде и идеята.
В крайна сметка не мисля, че може да има нещо в суапа след:
swapoff -a
dd if=/dev/zero of=/dev/swap bs=1024 count=bla bla
mkswap /dev/swap
swapon -a

аа, чакай сега малко

на мен поне до момента не ми стана ясно, че правих swapoff преди dd. при това положение мисля, че няма проблем да пишеш каквото си искаш на дяла за swap, обаче пък не виждам никакъв смисъл да го правиш.

след swapoff би следвало всичко от swap да е прехвърлено в оперативната памет (при условие че има достатъчно място разбира се), което само по себе си ще рече, че swap-а е празен. още повече, че mkswap ще пише върху нулите, които си написал точно преди него.