From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <3A96883B.18710B70@zmail.ru> From: cornet X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14-15mdk i686) X-Accept-Language: ru, en MIME-Version: 1.0 To: mandrake-russian@linuxteam.iplabs.ru Subject: Re: [mdk-re] Re: [mdk-re] =?koi8-r?Q?=EB=DC=DB=C9=D2=CF=D7=C1=CE=C9=C5=20=C4=C9=D3=CB=CF=D7?= References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Sender: mandrake-russian-admin@linuxteam.iplabs.ru Errors-To: mandrake-russian-admin@linuxteam.iplabs.ru X-BeenThere: mandrake-russian@linuxteam.iplabs.ru X-Mailman-Version: 2.0 Precedence: bulk Reply-To: mandrake-russian@linuxteam.iplabs.ru List-Help: List-Post: List-Subscribe: , List-Id: Mandrake/RE discussion list List-Unsubscribe: , List-Archive: Date: Fri Feb 23 18:56:10 2001 X-Original-Date: Fri, 23 Feb 2001 18:56:43 +0300 Archived-At: List-Archive: denf@novosoft.ru wrote: > > 02/23/2001 08:34:25 PM mandrake-russian-admin wrote: > >denf@novosoft.ru wrote: > >> > >> 02/23/2001 07:01:27 PM mandrake-russian-admin wrote: > >> >Откуда видно, что в свопе 33М, это те самые метры, которые на кэш > >> >отожраны, да еще и buffers 32М под себя отхватило. То есть если еще > чего > >> >то сильно юзающее винт позапускать, то начнет трэшить. > >> >А ведь конфигурацие не_попсовая, все таки 128М на борту. Вот и > >> >получается, что снижение пиковой дисковой активности за счет > избыточного > >> >кэширования оборачивается резким повышением этой самой активности за > >> >счет свопирования. > >> > > >> >Или я не прав? > >> Не прав ;-). Задача системы состоит в том, чтобы минимизировать > обращение к > >> диску,а не уменьшить обращение к свопу. Теоретически активность свопа > >> должна быть близка к активности файловых систем, хотя в десктопах, мне > >> кажется, это далеко от истины. > > > >Вот именно к десктопному использованию мои нарекания и относятся! > >Вообще говоря, дисковая активность складывается из активности файловой > >системы и свопирования, особенно актуально если винт один, да и еще > >не_UDMA. При работе на запись с кэшированием и без него, обьем записи, > >производимый диском всегда одинаков, разным будет только темп записи. > объем записи это еще не все - записать 10 блоков сразу и 10 блоков "по > одному" - большая разница, > придется лишних 8 раз ждать пока головка окажется в нужном месте. > > >При работе на чтение разница в темпе и обьеме работы диска будет только > >при повторном обращении к тем же файлам, если такового не происходит, > >значит кэширование работает впустую, то есть не как расширительный бачок > >а как длинная труба. > >Как раз при работе десктопной системы, ИМХО, повторные запросы к файлам > >имеют очень небольшие обьемы, а запись вообще происходит довольно таки > чтение и запись, не такие уж редкие операции - взять хотя бы обновление > access time для каждого открытого файла, > и размеры не очень маленькие - чего стоит одит каталог /dev > > >редко, зато свопирование, вызванное недостатком памяти под хранение кода > >и данных для жирных гуевых программ становится решающим фактором > >влияющим на суммарное быстродействие системы. > система на самом деле ведет себя очень разумно, и при нехватке памяти > первым под нож пойдет кэш, ^^^^^^^^^ Вот имено этого я не_наблюдаю :-(( На системах с 32М размер кэша доходит порой до половины общего обьема оперативки при том что в свопе 60-70М, причем не только пассивно висящие задачи (которые действительно вытесняются первыми) но и активно юзаемые в данный момент приложения, причем Alt-Tab в такой ситуации происходит с остервенелым хрустом винта. К сожалению я не могу сейчас воспроизвети описываемую ситуацию, у меня просто нет таких маленьких DIMM'ов, так что говорю по памяти. > ну и приложения, которые действительно не нужны > - > например, mingetty. При 128M памяти 30M кеша на 30M свопа - по-моему вполне > нормальная ситуация. > hint - запустите vmstat на длительный период и посмотрите работу кеша. Ok, понаблюдаю.... -- ******** FIRE & STEEL ********