Fedora and swap

[AlexM]

задача - иметь сервер без свапа. устал бороться
есть ява приложение, есть сквид. больше ничего нет. swapness = 1.
постоянно сваливается в свап, очень хочется узнать кто виновник.
вот состояние после свапа по данным free/ps_mem.py:

           total        used        free     shared    buffers     cached
Mem:        507936     504252       3684          0       7900      57048
-/+ buffers/cache:     439304      68632
Swap:      1349452     188452    1161000

 Private  +   Shared  =  RAM used       Program 

212.0 KiB +   0.0 KiB = 212.0 KiB       unlinkd
336.0 KiB +   0.0 KiB = 336.0 KiB       udevd
376.0 KiB +   0.0 KiB = 376.0 KiB       gpm
420.0 KiB +   0.0 KiB = 420.0 KiB       init
448.0 KiB +   0.0 KiB = 448.0 KiB       klogd
580.0 KiB +   0.0 KiB = 580.0 KiB       syslogd
592.0 KiB +   0.0 KiB = 592.0 KiB       crond
620.0 KiB +   0.0 KiB = 620.0 KiB       smartd
888.0 KiB +   0.0 KiB = 888.0 KiB       sh (2)
  1.6 MiB +   0.0 KiB =   1.6 MiB       mingetty (5)
  1.7 MiB +   0.0 KiB =   1.7 MiB       mc
  1.7 MiB +   0.0 KiB =   1.7 MiB       su (2)
  2.4 MiB +   0.0 KiB =   2.4 MiB       sendmail.sendmail (2)
  4.8 MiB +   0.0 KiB =   4.8 MiB       bash (4)
  5.1 MiB +   0.0 KiB =   5.1 MiB       sshd (3)
 46.6 MiB +   0.0 KiB =  46.6 MiB       squid (2)
320.7 MiB +   0.0 KiB = 320.7 MiB       java (2)

а вот состояние нормальное рабочее:

          total          used       free       shared    buffers     cached
Mem:        507936     483132      24804          0      13668      54364
-/+ buffers/cache:     415100      92836
Swap:      1349452          0    1349452

Private  +   Shared  =  RAM used       Program 

264.0 KiB +   0.0 KiB = 264.0 KiB       unlinkd
464.0 KiB +   0.0 KiB = 464.0 KiB       udevd
468.0 KiB +   0.0 KiB = 468.0 KiB       klogd
528.0 KiB +   0.0 KiB = 528.0 KiB       gpm
556.0 KiB +   0.0 KiB = 556.0 KiB       init
600.0 KiB +   0.0 KiB = 600.0 KiB       syslogd
820.0 KiB +   0.0 KiB = 820.0 KiB       smartd
  1.1 MiB +   0.0 KiB =   1.1 MiB       crond
  1.9 MiB +   0.0 KiB =   1.9 MiB       sh (2)
  2.0 MiB +   0.0 KiB =   2.0 MiB       mingetty (5)
  2.3 MiB +   0.0 KiB =   2.3 MiB       su (2)
  4.3 MiB +   0.0 KiB =   4.3 MiB       bash (3)
  5.7 MiB +   0.0 KiB =   5.7 MiB       sendmail.sendmail (2)
  6.0 MiB +   0.0 KiB =   6.0 MiB       sshd (3)
 34.5 MiB +   0.0 KiB =  34.5 MiB       squid (2)
337.5 MiB +   0.0 KiB = 337.5 MiB       java (2)

 Private  +   Shared  =  RAM used       Program 

Warning: Shared memory is not reported by this system.
Values reported will be too large, and totals are not reported

куда бы копнуть? а то тормозить начинает со свапом-то

[Pav]

ну не то чтобы совет, а так - идея вслух... Что если отключить swap и посмотреть что по аллокам в кору валить начнет...

[Troll]

swapoff -a

своп просто так не задействуется. если туда что-то ушло, это означает, что кому-то в какой-то момент не хватило оперативной памяти. => добавьте памяти.

а поднимать потом процессы из свопа просто так тоже нерационально, это будет происходить только когда они дождутся своей очереди на выполнение, а до того они так в свопе и будут лежать.

[rojer]

в ситуации 90% использования памяти заставить систему не свопиться можно только отключением свопа.
с другой стороны, тролль прав - а ты уверен, что это во благо? высвопляется ведь всего лишь небольшая часть твоей явы. в этой толстой туше вполне могут быть места, которые никогда не используются. оно тебе сильно мешает?

[AlexM]

Сообщение от rojer

в ситуации 90% использования памяти заставить систему не свопиться можно только отключением свопа.

а если 89% ? где граница-то? как вычислить?

Сообщение от rojer

оно тебе сильно мешает?

не мешало бы - нипочем не стал бы туда лезть, веришь, нет?.... дык мешает же, тормозить начинает . ну ладно бы свалилось в своп что-то ненужное и лежало бы там тихо - плевать, дык вмстат кажет что страницы из свопа тянутся.
собственно, яве жестко указано сколько памяти приложение может забирать. но это манагед память. есть еще системные ресурсы, те же сокеты. они вроде бы должны попадать в категорию buffers - но не видно чтобы их было неимоверно много..
собственно, вопрос заключался - как выцепить кто в своп падает, кому вдруг много памяти потребовалось.
кандидатов-то два всего, ява да сквид..

[nikulina]

да ява наверняка

а памяти нельзя добавить машинке?

[rojer]

проблема в том, что тебе не хватает памяти. смотри, в свопе лежат 185 мб, а кеша + free + buffers всего на ~70. если ты совсем вырубишь своп, то кого-то убьют. скорее всего твою драгоценную яву
либо уменьшай размер пула для явы и вырубай своп, либо добавляй памяти.

[AlexM]

Сообщение от rojer

проблема в том, что тебе не хватает памяти. смотри, в свопе лежат 185 мб, а кеша + free + buffers всего на ~70.

гы, дык вот на другой картинке памяти почему-то хватает. и так может продолжаться день-другой-третий, а потом бум - и в свапе.

Сообщение от rojer

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

ага, водъ мы и пришли к вопросу - кто виноват?
бо про сквид вон тоже пишуть что может вдруг память жрать ни с того ни с сего...
последовательная остановка того и другого приводит к последовательному уменшению свапа - т.е. оба там лежат. а вот кто инициатор?
как узнать сколько памяти резидентной + виртуальной + буферы + что-там-еще использует та или иная программа? судя по этому ps_mem памяти должно хватать.
куда копать?

AlexM добавил 26.06.2009 в 22:48

Сообщение от nikulina

да ява наверняка

а памяти нельзя добавить машинке?

за дополнительные деньги конечно можно. к сожалению, ежемесячные....

[rojer]

> гы, дык вот на другой картинке памяти почему-то хватает. и так может продолжаться день-другой-третий, а потом бум - и в свопе.

тут кандидатов два - либо сквид, либо ява меняют размер. причм сквид за этим не замечен, я подозреваю что яву периодически распирает сверх меры. показал бы, что ли, вывод ps aux - эта твоя странная утиля, похоже, не выводит vmsize, а по нему можно судить чьего тела больше в свопе лежит. то есть, чьи это 185 метров добра туда высвоплены.

[Troll]

Сообщение от AlexM

ага, водъ мы и пришли к вопросу - кто виноват?
бо про сквид вон тоже пишуть что может вдруг память жрать ни с того ни с сего...
последовательная остановка того и другого приводит к последовательному уменшению свапа - т.е. оба там лежат. а вот кто инициатор?
как узнать сколько памяти резидентной + виртуальной + буферы + что-там-еще использует та или иная программа?

и сквид может внезапно сожрать кусок памяти, обрабатывая параллельно много запросов, и джава может на ходу попросить ещё памяти. это не угадаешь, смотреть надо.

запускайте раз в минуту пс алwх, там отдельно выводится размер виртуальной памяти процесса и резидентной. стройте графики, смотрите, думайте

[alz]

Сообщение от AlexM

куда бы копнуть? а то тормозить начинает со свапом-то

Попробуй жабу урезать: -Xmx256m . Если ей с этого не поплохеет... Вообще конечно пытаться работать без свопа на полугиговой машине - верх мазохизма.

[vc]

Я бы переформулировал:
Пытаться запускать жабу на 500Мбайтной системе - верх мазохизма!

[AlexM]

Сообщение от Troll

и сквид может внезапно сожрать кусок памяти, обрабатывая параллельно много запросов, и джава может на ходу попросить ещё памяти. это не угадаешь, смотреть надо.

сквид запросы не обрататывает параллельно, он однопоточное приложение.
но память действительно может неожиданно пожрать, причем как я понял причина неизвестна и выход девелоперы предлагают один - перезапуск сквида .

Сообщение от Troll

запускайте раз в минуту пс алwх, там отдельно выводится размер виртуальной памяти процесса и резидентной. стройте графики, смотрите, думайте

я думал об этом, но тут какая фигня может случится. скажем, ява захотела многа памяти вдруг, система ей память даст, но при этом система легко память эту может взять у сквида, послав его в свап - в результате нифига я не увижу кто виновник, оба будут в свапе, а при неудачном расположении звезд в свапе окажется один сквид, хоть память потребовала ява.

AlexM добавил 27.06.2009 в 19:54

Сообщение от alz

Попробуй жабу урезать: -Xmx256m . Если ей с этого не поплохеет... Вообще конечно пытаться работать без свопа на полугиговой машине - верх мазохизма.

сейчас стоит -Xmx200m, но! это манагед память, отведенная под мой код, в которую не входят нативные ресурсы типа сокетов, стеков ниток и чего там еще есть.
ПЫСЫ а тебя не удивляет что на твоем телефоне ява вдруг работает? ты мазохист или у тя больше чем полгига памяти на борту?
этот явовский код + гуй к нему работает на SE P800, помнится у тебя такой был? 12 метров для всех приложений, из которых половину отбирала Opera... ессно вопрос не стоял в поддержке тысяч одновременнх коннектов, а только 16....

[Troll]

Сообщение от AlexM

сквид запросы не обрататывает параллельно, он однопоточное приложение.

однопоточность совершенно не мешает сквиду обрабатывать параллельно несколько запросов

Сообщение от AlexM

я думал об этом, но тут какая фигня может случится. скажем, ява захотела многа памяти вдруг, система ей память даст, но при этом система легко память эту может взять у сквида, послав его в свап - в результате нифига я не увижу кто виновник, оба будут в свапе, а при неудачном расположении звезд в свапе окажется один сквид, хоть память потребовала ява.

при сравнительном анализе общего количества памяти, занятого каждым процессом, вы увидите, кто из них недавно пожрал ещё памяти.

[AlexM]

Сообщение от rojer

показал бы, что ли, вывод ps aux

 %MEM   VSZ  RSS   COMMAND
61.8 446132 314276  java 
10.2 96764 51932  (squid)

             total       used       free     shared    buffers     cached
Mem:        507936     504624       3312          0       1680      28560
-/+ buffers/cache:     474384      33552
Swap:      1349452      63816    1285636

я, кстати, не понимаю этих цифр, как верняя табличка соотносится с 63816 из нижней?
есть у меня подозрение, что ps показывает заявленную память, а не реально использованную

AlexM добавил 27.06.2009 в 20:41

Сообщение от Troll

однопоточность совершенно не мешает сквиду обрабатывать параллельно несколько запросов

наверное мы по-разному понимаем слово "параллельно". но да бог с ним, не в том вопрос...

Сообщение от Troll

при сравнительном анализе общего количества памяти, занятого каждым процессом, вы увидите, кто из них недавно пожрал ещё памяти.

наверно так и буду копать, весьма здавая мысль