|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Victor Wagner 2:5020/400 25 Jun 2003 19:45:25
To : "U.P.Galyuck"
Subject : Re: swap
--------------------------------------------------------------------------------
U.P.Galyuck <galyuck@paloma.spbu.ru> wrote:
>>
>> Увы, разумность пределов устаревает тоже довольно быстро.
>> Учитывая старую добрую формулу SWAP=4*RAM двухгигового свопа уже мало.
>> Правда, с другой стороны у меня в машинах с гигом и более памяти диск
>> обычно тоже не один, так что два гига на шпиндель пока хватает.
UPG> У меня вызывает сомнение как раз эта формула при больших размерах
UPG> оперативки. Она эмпирически выведена во времена, когда для программ размер
UPG> кода и данных был соизмерим, и система занимала ощутимую часть ОП. Сейчас
UPG> программы разбухают в основном из-за объема данных - иначе несколько
А по-моему, наоборот - современные программы имеют безумно толстый код.
Особенно те, которые на C++ мозиллы там всякиие, не говоря уже про Java.
Причем заметная часть
того, что по смыслу код разделяется между процессами крайне хреново,
потому что это не машинный код, а скажем байткод, а то и
интерпретируемый исходник.
Если бы речь шла именно о коде, то с современными VM-подсистемами и
вопроса бы не стояло - код свопится обычно непосредственно из
исполняемого файла на диске (патологические случаи использования
компрессии исполняемых файлов или не PIC разделяемых библиотек, не
рассматриваем - они патологические)
UPG> гигабайт оперативной памяти просто не занять. У нас на кластере я ставлю
UPG> всего 1 Гиг свопа при таком же размере ОП, и считаю это перебором. Я не
UPG> представляю себе чем можно забить такой своп (у нас, правда система
UPG> очередей, и больше одного пользователя на машине не бывает). Потребность в
UPG> большом свопе мне представляется только в случае, если пользователь решит,
UPG> к
Так это во-первых, кластер, во вторых бэтчмодовый. Крайне узко
специализированная задача. А я об куда более распространенных задачах -
интернет-серверах, графических интерфейсах и т.п.
Там процессов обычно сотни, а то и тысячи.
Вот я сижу тебе письмо пишу. Сколько процессов задействовано?
1. X-сервер
2. Window Manager (он клавиатурным фокусом управляет)
3. Эмулятор терминала
4. Редактор
5. Hьюсочиталка (вот она-то как раз сидит и ждет, пока редактор свое
дело сделает. Вот ее-то и можно безболезненно отствопить)
А вокруг на экране еще с пару десятков программ. И я с ними не работаю в
данный момент. И добрую половину можно спокойно отсвопить.
А если я картинки редактирую и открыл 20 окон с 24-битными растрами
2048x1536 (с цифрового фотоаппарата - т.е. разрешение крайне небольшое)
в гимпе? Штук 18 из них можно спокойно отсвопить - оставить два - то, из
которого я копирую, и то в которое я копирую.
UPG> примеру, обращать большую матрицу, и заведет массив с размерами, заведомо
Hу не занимаются люди нынче в массе своей на компьютере обращением
матриц. То есть занимаются (половина тех же преобразований цвета на
матричной алгебре построена) но зачастую сами об этом не подозревают.
Вот видео поредактироовать или базу данных какую полопатить - это да.
В принципе, даже база данных - абстракция для не-конечного пользователя.
Конечный пользователь будет на этом копьютере "квартальный финансовый
отчет делать". А то что там внутри база данных - так это неонка такая,
на то программисты есть чтобы ее крутить.
UPG> Впрочем, допускаю, что вывод о рекомендуемом размере свопа тесно связан
UPG> с условиями работы компьютера (что за задачи, какие пользователи), но
UPG> подозреваю, что когда на машине захотят работать одновременно 100
UPG> пользователей, запустив задачи по 40 Мб (в сумме как раз 4 ГБ), то в такой
Там захотят работать 10 пользователей, и запускать будут процессы по 4Мб
(хотя 40 это как раз типичный RSS для мозилки). Hо по 100 штук каждый.
А помимо этого там будет крутиться какой нибудь сервер даз банных,
который замлочит мегабайт этак несколько сот под свои кэши, племя
краснокожих (апачей) экзепляров этак из ста (и каждый экземпляр
экземпляру lupus est, поскольку там mod_perl или mod_php с кучей
скриптового кода)
--
--- ifmail v.2.15dev5
* Origin: Free Net of Leninsky,45 (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
| Тема: |
Автор: |
Дата: |
|
Re: swap |
U.P.Galyuck |
25 Jun 2003 16:21:39 |
 Re: swap |
Victor Wagner |
25 Jun 2003 17:34:38 |
  Re: swap |
U.P.Galyuck |
25 Jun 2003 19:09:07 |
 Re: swap |
Victor Wagner |
25 Jun 2003 19:45:25 |
|
Re: swap |
Pavel Marenyuk |
25 Jun 2003 22:17:37 |
|
Re: swap |
Dmitry Melekhov |
26 Jun 2003 21:23:47 |
|
Re: swap |
Serguei Khvatov |
27 Jun 2003 11:40:36 |
|
Re: swap |
Eugene Morozov |
26 Jun 2003 09:54:02 |
|
Re: swap |
Victor Wagner |
26 Jun 2003 10:28:56 |
|
Re: swap |
Eugene Morozov |
26 Jun 2003 14:46:58 |
|
Re: swap |
Valentin Nechayev |
26 Jun 2003 11:11:24 |
|
|
