Дедик и сиджи что делать?:) оперативка.

снести апач и поставить nginx, если еще не сделано

эднжин х стоит с самого начала еще

vlad3d писал:

Поставил snmp мониторинг. Вот этим мерили админы я не мерил

Ну и по какому параметру мерили?

Если по free RAM - то могут засунуть себе результаты в одно место :] Потому как OS нормальная стремится вообще не оставлять RAM неиспользованной, а использует под кыш сколько можно. У меня сейчас тоже на домашней машине свободно 33MB из 4GB. Но следствие легко покажет, что там 3GB под кэш файлов ушло.

top в студию )
да и в чем проблема то, не ложится же пока сервер? )

когда ляжет поздно будет. просто скоко можно туда еще забабахать сиджей 10 еще влезет?

vlad3d: Ниша какая ? О каких объёмах сиджей (добавить ещё) идёт речь - скрипты какие, трафф, к-во галер со старта какое планируется ?

vlad3d писал:

когда ляжет поздно будет. просто скоко можно туда еще забабахать сиджей 10 еще влезет?

Да кто ж тебе так скажет наугад? Запускаешь "vmstat 5" и анализируешь free memory и cache. Вообще более правильно поставить sysstat и sar -r смотреть, что там по used. Но самое правильное - наблюдать за работой свопа. Сколько swap in/out идет в vmstat. Если началось - да, пора задуматься. Но ничего еще не ляжет пока. Нынешние OS довольно хорошо свапом умеют пользоваться, и прежде, чем начнутся реальные тормоза, еще времени будет достаточно для тьюнинга. Так вообще наугад никто ничего не сможет сказать. Это надо брать и смотреть на месте, проверять, если нужно - оптимизировать. А то точно, как кто-то тут уже такие топики характеризовал - "чувствую себя хорошо, что б еще такого попить, чтоб не заболеть?"

Цитата:

А зачем nginx на отдельном iP ставить? Его нужно основным вебсервером и беком к нему Апач.

в рунете не достаточно насмотрелся ошибок nginxa о связи с бакендом ?

Отдельный дедик это и плюс и минус одновременно. С одной стороны распределяется нагрузка, с другой стороны в 2 раза увеличивается шанс, что или один или второй сервак подохнет по какой то причине.

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

а нафиг там бэкэнд вообще?
если скрипты на пхп, nginx сам прекрасно со всем справляется.

короче пробовать надо с учетом всего вышесказанного ясно.

color писал:

если скрипты на пхп, nginx сам прекрасно со всем справляется.

...да в принципе и апач, над которым поработали и настроили, должен не хуже бы справиться без всякого нгинкса. Есть желающие проэкспериментировать? ;) Сделаю бесплатно, чисто интереса ради. Просто нету под рукой сервера с нагрузкой такой, что действительно надо попотеть, чтобы запыхтело

Dr.Syshalt писал:

...да в принципе и апач, над которым поработали и настроили, должен не хуже бы справиться без всякого нгинкса. Есть желающие проэкспериментировать? ;) Сделаю бесплатно, чисто интереса ради.Просто нету под рукой сервера с нагрузкой такой, что действительно надо попотеть, чтобы запыхтело

Оффтопик: Когда мы потеряем dlk, я знаю кто займёт его место

PS. Смотреть в топ. выкинуть mysql, поставить dtr. нагрузка должна значительно уменьшиться....

Цитата:

Когда мы потеряем dlk, я знаю кто займёт его место

Оффтопик: dlk, он как чёба - пока сам не потеряется никто его потерять не сможет, по моему

Цитата:

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

У меня прощание с 18-20 (точно не помню) стримами на подобном сервере с мелкими сиджами снизило нагрузку втрое минимум, это при том, что тумбы все были уже сграбленные и отротированные. Стрим, имхо, самый тяжёлый из распространённых сиджевых скриптов в случае, если сиджей на серваке много (>15) (это не значит, что стрим плохой, просто юзать его при наличии множества мелких сиджей - не совсем рационально).

Woland писал:

Оффтопик: dlk, он как чёба - пока сам не потеряется никто его потерять не сможет, по моему

Оффтопик: Он как летун. dlk незаменимый

allendale писал:

Оффтопик: Когда мы потеряем dlk, я знаю кто займёт его место

Ты сам пробовал апач с другим mpm кроме preforkа?

Woland писал:

У меня прощание с 18-20 (точно не помню) стримами на подобном сервере с мелкими сиджами снизило нагрузку втрое минимум, это при том, что тумбы все были уже сграбленные и отротированные. Стрим, имхо, самый тяжёлый из распространённых сиджевых скриптов в случае, если сиджей на серваке много (>15) (это не значит, что стрим плохой, просто юзать его при наличии множества мелких сиджей - не совсем рационально).

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

второй дедик лучше взять ИМХО... я так и сделал когда сервак пару раз лег

Влад, по-моему, ты все-таки несколько перестраховываешься ;)

На твоем сервере запас производительности еще приличный. Мускуль оттюнен. Памяти сводобной достаточно + память выделенная под кэш фс. Своппинга нет и в помине. Нагрузка на диски совсем не большая.
Единственное что ЛА подскакивает когда запускается пачка кронов. Тут тебе поможет совет приведенный выше - запускать их последовательно.

Dr.Syshalt писал:

...да в принципе и апач, над которым поработали и настроили, должен не хуже бы справиться без всякого нгинкса. Есть желающие проэкспериментировать? ;) Сделаю бесплатно, чисто интереса ради. Просто нету под рукой сервера с нагрузкой такой, что действительно надо попотеть, чтобы запыхтело

Да ты из конфига Апача опубликуй те места которые настроил - а я у себя попробую что это даст.

действительно а апач у тебя с MPM работает ?
worker или prefork ?
попробуй на prefork перенести

KeepAlive включен ?
какова загрузка системы по top'у

вообще мало вводной инфы
6 мбит это не так много на самом деле для такого сервера
в свое время у меня на p4 с 1Гб 10-20 мбит свободно держал 1.3 апач

как вариант вывод картинок повесить на nginx да и апач немного походуеть за счет выкидки лишних модулей может

есть вариант даже запуска 3 веб серверов
1) nginx для картинок
2) apache для всего что не юзает php (например у меня at3 и ротатор Rolling) так вот at3 юзает легкий апач а админка ротатора (так как много ресурсов ей надо но редко они используются на тяжелом апаче)

3) апач для админок (тяжелый с php)

короче вариантов решения и оптимизации масса

Stek писал:

в рунете не достаточно насмотрелся ошибок nginxa о связи с бакендом ?

Ну у меня были ошибки Апач не успевал данные отдать нгинксу - увеличил таймаут в нгинксе все стало OK.

PistoGanza писал:

Влад, по-моему, ты все-таки несколько перестраховываешься ;) На твоем сервере запас производительности еще приличный. Мускуль оттюнен. Памяти сводобной достаточно + память выделенная под кэш фс. Своппинга нет и в помине. Нагрузка на диски совсем не большая. Единственное что ЛА подскакивает когда запускается пачка кронов. Тут тебе поможет совет приведенный выше - запускать их последовательно.

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

El Nino писал:

действительно а апач у тебя с MPM работает ? worker или prefork ? попробуй на prefork перенести

Доки почитай, что ли... prefork - это порождение нового процесса на каждый запрос. И это как раз самая тормозная и прожорливая модель, установленная по умолчанию потому, что под нее много модулей написано, и далеко не факт, что все они заработают в multithreaded-среде. В том числе со многими php extensions может быть проблем достаточно - в случае использования mod_php. И большинство народу даже доку не читает, а оттуда можно узнать, что есть worker - это когда порождается новый thread, что уже экономит много ресурсов и много быстрее. Есть еще mpm event - этот mpm работает сходно с тем, как работает nginx, там точно так же работа делается через epoll и kqueue. Проблема с последним только в том, что не будет работать mod_ssl и input-фильтры. Короче, есть в открытом доступе мануал апача, который можно почитать и разобраться. Еще в дополнение можно поудалять кучу ненужных модулей (типа mod_info, mod_usertrack) и перестать использовать .htaccess, чтобы апач на каждый запрос не шарился по куче директориев - директива AllowOverride None, единственная на весь конфиг. Также отключить MultiViews, поскольку оно тоже неслабо нагружает сервер - апач опять же проверяет несколько файлов на каждый запрос. Это все - первое, что в голову приходит.

El Nino писал:

вообще мало вводной инфы 6 мбит это не так много на самом деле для такого сервера в свое время у меня на p4 с 1Гб 10-20 мбит свободно держал 1.3 апач

Я, кстати, тоже не понимаю - у меня такое впечатление, что проблемы чисто надуманы. Имел честь иметь фрихостинг interpornnet.com (уже не работает, чисто fhg остались) на P3 512MB (Sun Cobalt RAQ 550) и безлимитным каналом на 10Mbps, там чего только не крутилось, народу было - многие десятки, в том числе и с сиджами. Апач 1.3 - который был пересобран так, чтобы разрешать 512 одновременных коннектов, ибо с дефолтными 256 не держал, вот и весь "тьюнинг". И канал там забивался постоянно, но ни разу не было, чтобы оно упало, аптайм в сотни дней был (перезагружал только по апдейтам кернела, а то бы все несколько лет простоял)

У меня даж мысль появилась, что хостер просто разводит на добавление памяти

Dr.Syshalt писал:

Доки почитай, что ли... prefork - это порождение нового процесса на каждый запрос. И это как раз самая тормозная и прожорливая модель, установленная по умолчанию потому, что под нее много модулей написано, и далеко не факт, что все они заработают в multithreaded-среде. В том числе со многими php extensions может быть проблем достаточно - в случае использования mod_php. И большинство народу даже доку не читает, а оттуда можно узнать, что есть worker - это когда порождается новый thread, что уже экономит много ресурсов и много быстрее. Есть еще mpm event - этот mpm работает сходно с тем, как работает nginx, там точно так же работа делается через epoll и kqueue. Проблема с последним только в том, что не будет работать mod_ssl и input-фильтры. Короче, есть в открытом доступе мануал апача, который можно почитать и разобраться. Еще в дополнение можно поудалять кучу ненужных модулей (типа mod_info, mod_usertrack) и перестать использовать .htaccess, чтобы апач на каждый запрос не шарился по куче директориев - директива AllowOverride None, единственная на весь конфиг. Также отключить MultiViews, поскольку оно тоже неслабо нагружает сервер - апач опять же проверяет несколько файлов на каждый запрос. Это все - первое, что в голову приходит. У меня даж мысль появилась, что хостер просто разводит на добавление памяти

Про prefork ты прав, но не совсем. Он создает также пул запущеных, готовых к работе child-процессов, память между которыми шарится, и не сильно тратится во время ожидания. Да и память сейчас - не самый дорогой ресурс.
По скорости работы на сиджах скажу, что worker быстрее на 3-5% всего отрабатывал, и то не во всех случаях, но с ним часто бывают приколы, когда процесс залипает, и убить его нельзя, разве что ребутом машины.
Я думаю, что только поэтому большинство юзает апач1 или апач2(префорк).
Доки читают многие, но не многие понимают. Есть еще шишки от граблей, по которым ходят и набираются опыта.

Про .htaccess - за гибкость конфигурирования надо чем-то расплачиваться, вот и расплачиваемся производительностью.

давайте не будем столь однозначно делать выводы на счет MPM
потому что везде есть свои ньюансы

вот человеку вводная инфа по сравнению MPM моделей
http://phpsuxx.blogspot.com/2008/01/apache2-prefork-vs-worker.html
пусть почитает ознакомится
никто же не знает чего творится на его сервере...

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