* Re: [mdk-re] Re: [mdk-re] Кэширование дисков
@ 2001-02-23 18:42 denf
2001-02-23 18:56 ` cornet
0 siblings, 1 reply; 2+ messages in thread
From: denf @ 2001-02-23 18:42 UTC (permalink / raw)
To: mandrake-russian
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
>редко, зато свопирование, вызванное недостатком памяти под хранение кода
>и данных для жирных гуевых программ становится решающим фактором
>влияющим на суммарное быстродействие системы.
система на самом деле ведет себя очень разумно, и при нехватке памяти
первым под нож пойдет кэш, ну и приложения, которые действительно не нужны
-
например, mingetty. При 128M памяти 30M кеша на 30M свопа - по-моему вполне
нормальная ситуация.
hint - запустите vmstat на длительный период и посмотрите работу кеша.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [mdk-re] Re: [mdk-re] Кэширование дисков
2001-02-23 18:42 [mdk-re] Re: [mdk-re] Кэширование дисков denf
@ 2001-02-23 18:56 ` cornet
0 siblings, 0 replies; 2+ messages in thread
From: cornet @ 2001-02-23 18:56 UTC (permalink / raw)
To: mandrake-russian
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 ********
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2001-02-23 18:56 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-02-23 18:42 [mdk-re] Re: [mdk-re] Кэширование дисков denf
2001-02-23 18:56 ` cornet
ALT Linux Community general discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/community/0 community/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 community community/ http://lore.altlinux.org/community \
mandrake-russian@linuxteam.iplabs.ru community@lists.altlinux.org community@lists.altlinux.ru community@lists.altlinux.com
public-inbox-index community
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.community
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git