Проблемы с доступом на сайт 23го мая (было: что было с сайтом?)

[abg]

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

Если это баг или хак то смысла нет - как выело 256 так выест и 512.
Может попробовать мониторить использование памяти по процессам в течении пары-тройки недель?

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

гарантия в 256 Mb - это RAM + swap. мониторить будем, куда деваться. кусаем больше, т.к. каждый процесс php просит 12-16 метров. в wiki - 20, в галерее - 32 метра на запрос. поэтому апач и запрашивает память, которую далеко не всегда потом использует.

[YellowMan]

Сегодня днем база сломалась?

[YellowMan]

Сегодня не работает "быстрый ответ" - "медленный" тоже не работает.
Почему-то только в ИТ. Почему-то только в темах про Линух. Почему-то только у меня

YellowMan добавил 01.06.2007 в 12:54

[abg]

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

[YellowMan]

типа dull messages теперь писать ?

[rojer]

abg> У меня на работе был открытый шелл - но даже на нем любая команда просто выдавала "-bash: fork: Cannot allocate memory"
abg> Ясно было одно - что с машиной сделать ничего было нельзя.

а можно было попробовать.
это хороший вопрос для interview

[abg]

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

abg> У меня на работе был открытый шелл - но даже на нем любая команда просто выдавала "-bash: fork: Cannot allocate memory"
abg> Ясно было одно - что с машиной сделать ничего было нельзя.

а можно было попробовать.
это хороший вопрос для interview

слушаю внимательно, тов. роджер

[rojer]

kill не даром сделана встроенной командой.
осталось найти - кого. ps не запустится, но /proc на линуксовой машине наверняка смонтирован (вроде и в vz он тоже поддерживается), так что список пидов найдём там.
в принципе, уже можно начать отстрел: найти пиды с последовательными номерами и выстрелить в гущу - с большой вероятностью попадёшь в дитё апача
убить пид 1 или себя будет плохой идеей, так что для начала проверим $$ и не будем убивать этот процесс.
если есть время, то можно и поумничать: пройтись по /proc/XXX/cmdline и найти апачевские процессы. сделать это в условиях, когда ни find, ни cat не запустятся будет не так просто, но для получения содержимого файла без форканья подойдёт такая конструкция:
read XXX < /proc/1/cmdline; echo $XXX
read и echo - тоже встроенные команды.
вот примерно так

[abg]

уже вижу, как перебираю 65535-1 pidа киллами

[rojer]

# for F in /proc/*/cmdline; do echo -n "$F "; read CMD < $F; echo $CMD; done

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

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

[abg]

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

что касается worker mpm + mod_php - в нем что, уже mod_php нормально стал работать в тредах?

[rojer]

> grep httpd бы не сработал.
ну я имел в виду - глазами
или копипастом в другое окошко, где можно и прогрепать, и пиды из имён файлов выделить.
> кстати, никогда не приходилось пробовать - бэш комплишн работает, когда на компе память кончилась?
работает, т.к. не форкает новых процессов.
конечно, если тебе сильно не повезёт, и для таб-комплишна потребуется, допустим, ещё одна страничка памяти, а её уже совсем, ну просто вообще никакой нет, то опаньки.
> убить все процессы было бы можно... только никогда не знаешь, что убьется первым - твой шелл или кушавшие память процессы, верно?
ну ёлы палы, я ж показал, как выделить именно то, что хочется.
главное не убить инит (pid 1) и себя (pid $$, сделать echo $$ и посмотреть)

> что касается worker mpm + mod_php - в нем что, уже mod_php нормально стал работать в тредах?
сам по себе php вполне thread-safe и уже давно. проблемы возникают с некоторыми его екстеншнами. на прошлой работе я перевёл несколько немаленьких проектов под apache 2.x/worker, в том числе и с mod_php (e.g. games.cnews.ru написан на php, стоит форум от vbulletin) и всё ok. благодаря этому мне не пришлось городить огород с проксированием, а нагрузочная способность в коннектах значительно повысилась. кроме того, всегда есть prefork, на который можно откатиться. коллега говорил, что 2.x/prefork + mod_php (он не рискнул делать это у себя) всё равно жрёт памяти меньше, чем 1.x + mod_php, т.е. выгода от перехода на 2.x всё равно есть.

[abg]

k 10x

кстати, я тут подумал - ведь в vm есть параметр настраиваемый min_free_kbytes. почему бы не сделать подобное как в ext2/3 с минимальной резервацией памяти под рутовые процессы?