LINUX.ORG.RU

Linux Kernel 2.4 needs SWAP = 2xRAM


0

0

Если Вы используете Linux kernel 2.4 и у Вас кое-что попадает в своп - Вам полезно будет узнать, что в новом кернеле стратегия работы со свопом изменилась, что портребует переосмысления понятия "достаточный размер свопа"

>>> Подробности

★★★★★

Проверено:

> скажите пожалуйста, _нужен_ ли своп 2xRAM в 2.4, или нет.
Не обязателен, просто в случае сильной загрузки при таком swap работать будет побыстрее.
Т.е. неактывный процесс "втихаря" дублируется в swap, понадобилась память - система просто передаёт эту память запросившему - процесс-то уже в свапе... В обзем-то это должно положительно сказаться на всех системах, действительно использующих свап.

А так... Он вообще не обязателен, если ОЗУ заведомо достаточное кол-во.

AffreuxChien
()
Ответ на: комментарий от Korwin

2Korwin:
Вы наверное невнимательно читали, или знаки препинания у меня не те? :)
Блин, так он и не должен уходить в swap!
Я ж говорю: Oracle swap не любит, и если не удается впихнуть в RAM его,
то нужно бежать за памятью, а не увеличивать swap!
Уточняю: речь идет об Oracle System Global Area. В swap позволительно пускать
только users session процессы.
Да я согласен, что все можно поднастроить: например в 8i уменьшить
java_pool_size (если не используется java) - по умолчанию уж очень большой он.
Oracle Tunning&Performance - тема отдельного сайта, наверное.

IMHO, не нужно заставлять таки Oracle уходить в swap!

Вопрос(offtopic): что означает "10-20% при старте"? 50-100M?
Я точно могу сказать сколько у меня на старте отжирает Oracle.
И сколько при работе. 96M и 14М на каждый коннект соответственно.

sandman
()

Жил спокойно на ядре 2.2.16 Вебсервер (136 виртуальных сайтов с 
нехилой загрузкой - многие сайты лидируют во всяких Рамблерах и т.д.)
Машина - Intel ISP 2150
2 x Pentium III - 596.933Mhz
SDRAM - 256
SWAP - 256
Загрузка
        total       used       free     shared    buffers     cached
Mem:    257464     253972       3492     210768      42416      47260
-/+ buffers/cache:     164296      93168
Swap:       511132       5700     505432
Апгрейдился без изменений в конфигурации до 2.4.2 - две недели uptime 
без проблем, потом в kern.log - __alloc_pages failed и так несколько 
сот тысяч раз. При этом Апачи не отвечает ни на один запрос, кстати 
заметил что после этого shared memory - 0.
maul:/var/log# free
       total       used       free     shared    buffers     cached
Mem:   255796     251536       4260          0       3704      26204
-/+ buffers/cache:     221628      34168
Swap:       248996       9544     239452

срочно был проведен даунгрейд
до 2.2.18, в субботу, воскресенье сервер вел себя достойно, не 
капризничал.
В понедельник в логах ядра появилось следующее,
---------------------------------------------
Mar 19 14:59:47 maul kernel: VM: do_try_to_free_pages failed for kupdate...
Mar 19 14:59:47 maul last message repeated 3 times
---------------------------------------------
apache при этом не отвечает ни на какие запросы в его логах чисто...

То выделить, теперь освободить не может...
Может с диском проблемы - я прав в своих предположениях ?

Проблемы со свопом во всех случаях, своп практически не используется -
 наращивать его по моему незачем... Хотя мне посовтовали 2.2.19pre2 
ядро поставить, там мол решены проблемы с яром - только я этого ядра 
вообше не нашел... 
Какие мысли? В чем причина ?

BeerBong
()

ищи патчи 2.2.19-preX в каталоге Алана www.kernel.org:/pub/linx/kernel/peoples/alan/... дальше будет понятно Удачи .

anonymous
()
Ответ на: комментарий от BeerBong

To BeerBong (*) (2001-03-20 09:44:39.0). Извиняюсь спросить, а зачем на 2.4.2 переходил если все толком работало?

Dodo
()

господа А у меня на работе сервер и 4 тачки с 1Gb RAM. Только нам этого мало а нужно 4Gb RAM...И еще винт под СВАП?!!!? ;((

anonymous
()

2bormotov: cat /proc/stat , man proc
2Irsi: на днях поменял свои 32Mb на 128 и теперь, наверно, о сжатии памяти забуду года на полтора, хотя, в принципе можно представить ситуацию в которой простенький алгоритм сжатия (только удаление нулей, например) может даже увеличить производительность за счет использования cpu cache(c сжатыми HDD так бывало)

К слову:"...Размер области подкачки обычо выбирают в два раза больше размера оперативной памяти. Тем не менее,32-48Mb обычно заведомо достаточно для большинства применений..."
М.Шойхер: "Как установить Linux на ваш компьютер" М:ООО МФС,1997г.

Anonymous ★★★★★
()

2Anonymous: мазилу, наутилус и т.д. поставишь - сразу опять вспомнишь...:)
Вообщем да - модификация не слишком сложная... Ктоб занялся - пачь такой к ядру сделать? Интересно было бы проверить как работать будет...:) Вообщем как делать понятно - создаем буфер, для сжатых страниц, ну и соответственно две очереди - одня обычная, другая - для сжатых страниц... И алгоритм сжатия - на эффективность положить, в 1.5-2 раза за глаза, главное чтоб быстрый был... лучше без плавающей точки...
Блин, мыша цитировать не надо, ок? :) Ты с ним на канале пообщайся...:-/

Irsi
()

поиздевался слегка:

$kill -s SEGV .....
$cat core | tr -d '\0' > coremin0

1.6M ./ElectricEyes/core (Jpeg 400*400 )
663k ./ElectricEyes/core.bz2
1.0M ./ElectricEyes/coremin0
634k ./ElectricEyes/coremin0.bz2

12M ./ac3d/core (.3ds 6500 вершин)
1.1M ./ac3d/core.bz2
3.1M ./ac3d/coremin0
1.0M ./ac3d/coremin0.bz2

576k ./ghostview/core (.pdf 2 листа)
135k ./ghostview/core.bz2
229k ./ghostview/coremin0
121k ./ghostview/coremin0.bz2

824k ./gnp/core (.c ~6Kb)
201k ./gnp/core.bz2
341k ./gnp/coremin0
181k ./gnp/coremin0.bz2

212k ./top/core
45k ./top/core.bz2
68k ./top/coremin0
41k ./top/coremin0.bz2

956k ./wordview/core
246k ./wordview/core.bz2
502k ./wordview/coremin0
228k ./wordview/coremin0.bz2

cat /dev/hda3 > /tmp/swap (не так грубо, как кажется)
(Когда и чем swap последний раз был заполнен до упора- не представляю)

45M /tmp/swap
37M /tmp/swapmin0

2.5M /tmp/swap.bz2
2.3M /tmp/swapmin0.bz2

Kernel 2.6 nidded swap 6Mb?
Интересно, win(kak tam?).swp также выглядит?

Anonymous ★★★★★
()

Мораль: сжимать и разжимать память можно быстрее, чем работать с любым диском, теоретически при работе с памятью процессор занят, а время затраченное на доступ к диску одной задачей может быть использованно другой, но реально уменьшение времени реакции почти всегда важнее

Раньше програмисты помнили Assembler, знали, что такое байты и не использовали int[] для хранения номеров палцев ради сомнительного прироста производительности, а значит тот же коэффицент сжатия требовал больше ресурсов(если был возможен)

Anonymous ★★★★★
()

2Anonymous: ну сделай патчь к ядру, который сжимает, прежде чем в свап отправлять? Посмотрим насколько эффективно работать будет... Действительно интересно...
Да, не знаю как в линуксе, не ковырял если честно, но в нормальных ОС свапятся только сегменты данных, сегменты кода просто дискардятся, а если потребуются опять - просто подкачиваются из бинарного образа...:) В принципе это должно сыграть на руку сжатию - код в общем случае жмется хуже данных... В _обшем_ случае, а не всегда, прошу заметить!

Irsi
()

На subj. Выдержка из мануала к Linux-Mandrake 7.2
The rule of thumb for the swap partition size is to choose the same size as your RAM memory. However for large memory configurations (>128Mb), this rule is not valid, and smaller sizer are preferred.
<-..-> Размер swap вибирайти по размеру таким же сколько у вас RAM. Если у Вас памяти больше 128Мб, то это правило уже не действует и swap меньшего размера (меньше 128Мб) только приветствуется.

Korwin ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.