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

[Oleg123]

сабж собственно. кто нибудь расскажет, а том мы волновались

[Beara]

Уфффффф!... с сайтом... А я-то думала мине наши админы уже доступ на сайт перекрыли, за мис'юз инернета в рабочее время....

[abg]

Проблемы начались сегодня утром в 4:56. Причины пока неизвестны, выясняем. Ясно было одно - что с машиной сделать ничего было нельзя. Даже соединения по ssh к ней не проходили. У меня на работе был открытый шелл - но даже на нем любая команда просто выдавала "-bash: fork: Cannot allocate memory". Тех. поддержка провайдера пока не откликнулась.

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

Тему перенесу позже в "Новости сайта"

[Oleg123]

А хостинг в какой стране физически, в России?
В качестве гипотетической идеи - может имеет смысл сюда на остров переместиться, правда придется переименоваться в .net или .org, но .ru по идее можно алиасом сохранить.

[YellowMan]

Переходили бы вы уже на Windows что-ли...

[Света Свисс]

Теперь понятно, почему я всё утро не могла зайти на форум.

[zdragon]

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

Переходили бы вы уже на Windows что-ли...

+1

[abg]

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

А хостинг в какой стране физически, в России?
В качестве гипотетической идеи - может имеет смысл сюда на остров переместиться, правда придется переименоваться в .net или .org, но .ru по идее можно алиасом сохранить.

хостинг давно уже в штатах

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

Переходили бы вы уже на Windows что-ли...

ви-таки хотите, чтобы фо'гум совсем исчез?

[alz]

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

Переходили бы вы уже на Windows что-ли...

железо спонсируешь?

[YellowMan]

железо спонсируешь?

Виртуальные хосты стоят одинаково

ви-таки хотите, чтобы фо'гум совсем исчез?

Скорее наоборот
Интересно-таки что вам суппорт ответит? Вы же шарите? Наверняка другой клиент весь могк выел...

[alz]

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

Виртуальные хосты стоят одинаково

"Где бы что ни говорили -
все одно сведеть на бабъ!" (С)

Далась тебе эта стоимость. Время отклика смотри! А оно у IISa мягко говоря не выдающееся, на внутреннем сервере ежеутренне наблюдаю первую загрузку index.asp по 10 секунд..

Пров на shared сервере криво лимиты ресурсов разрулил, всего-то..

[abg]

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

Виртуальные хосты стоят одинаково

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

Скорее наоборот
Интересно-таки что вам суппорт ответит? Вы же шарите? Наверняка другой клиент весь могк выел...

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

[YellowMan]

Расскажите если найдете - мне правда интересно, без подколок

[abg]

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

Расскажите если найдете - мне правда интересно, без подколок

сегодня полдня разбирался с виртуализацией virtuozzo, на которой и сделан наш хостинг. история пока такова:

вчера в 5 утра мы уперлись в ограничение privvmpages - то есть ограничение на количество malloc памяти. однако понять, чтоже все-таки случилось, сложно по многим причинам:

гарантированное количество памяти на нашем VPS - 256 мб. обычно у нас постоянно занято около 450мб. когда я говорю "занято", я не имею в виду, что оно "используется". делать malloc - это занять память. делать memset на этот malloc - уже начать эту память использовать. то есть несмотря на то, что занято у нас 450 обычно мб, реально используется только 138мб.

сейчас на хостинге для упирания в privvmpages мне пришлось попросить у системы через malloc 4(!) Гб памяти. наша система никогда столько не занимала. хотя с момента перезагрузки VPS количество неуспешных mallocов равняется 417517, т.е. чуть меньше полумиллиона.

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

таким образом, вариантов развития событий я вижу два:

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

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

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

в связи со сложившейся ситуацией можно предпринять несколько вещей.
1) установка более подробной системы мониторинга и раннего предупреждения о проблемах
2) установка системы, которая сможет рестартовать разгулявшиеся процессы. делать придется руками, т.к. все динамические интерпретаторы не годятся - они даже работать не смогут, если в системе нет памяти.
3) переход на более легковесное ПО, вместо apache + mod_php. например, на тот же nginx + fastcgi.
4) установка proxy перед апачем. в качестве proxy может выступать nginx, squid, еще много чего.
5) переход на следующий ценовой план, с гарантированными 512 мегабайтами памяти.

[YellowMan]

переход на следующий ценовой план, с гарантированными 512 мегабайтами памяти.

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

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