Master-X
Регистрация
|
Вход
Форум
|
Новости
|
Статьи
Главная
»
Форум
»
Хостинги / Домены / Железо
»
Тема:
Дедик и сиджи что делать?:) оперативка.
Новая тема
Ответить
цитата
18/06/09 в 22:44
color
снести апач и поставить nginx, если еще не сделано
цитата
18/06/09 в 22:46
vlad3d
эднжин х стоит с самого начала еще
цитата
18/06/09 в 23:00
Dr.Syshalt
vlad3d писал:
Поставил snmp мониторинг. Вот этим мерили админы я не мерил
Ну и по какому параметру мерили?
Если по free RAM - то могут засунуть себе результаты в одно место :] Потому как OS нормальная стремится вообще не оставлять RAM неиспользованной, а использует под кыш сколько можно. У меня сейчас тоже на домашней машине свободно 33MB из 4GB. Но следствие легко покажет, что там 3GB под кэш файлов ушло.
цитата
18/06/09 в 23:07
color
top в студию )
да и в чем проблема то, не ложится же пока сервер? )
цитата
18/06/09 в 23:15
vlad3d
когда ляжет поздно будет. просто скоко можно туда еще забабахать сиджей
10 еще влезет
?
цитата
18/06/09 в 23:19
Woland
vlad3d:
Ниша какая ?
О каких объёмах сиджей (добавить ещё) идёт речь - скрипты какие, трафф, к-во галер со старта какое планируется ?
цитата
19/06/09 в 00:01
Dr.Syshalt
vlad3d писал:
когда ляжет поздно будет. просто скоко можно туда еще забабахать сиджей
10 еще влезет
?
Да кто ж тебе так скажет наугад? Запускаешь "vmstat 5" и анализируешь free memory и cache. Вообще более правильно поставить sysstat и sar -r смотреть, что там по used. Но самое правильное - наблюдать за работой свопа. Сколько swap in/out идет в vmstat. Если началось - да, пора задуматься. Но ничего еще не ляжет пока. Нынешние OS довольно хорошо свапом умеют пользоваться, и прежде, чем начнутся реальные тормоза, еще времени будет достаточно для тьюнинга. Так вообще наугад никто ничего не сможет сказать. Это надо брать и смотреть на месте, проверять, если нужно - оптимизировать. А то точно, как кто-то тут уже такие топики характеризовал - "чувствую себя хорошо, что б еще такого попить, чтоб не заболеть?"
цитата
19/06/09 в 00:24
Stek
Цитата:
А зачем nginx на отдельном iP ставить? Его нужно основным вебсервером и беком к нему Апач.
в рунете не достаточно насмотрелся ошибок nginxa о связи с бакендом ?
Отдельный дедик это и плюс и минус одновременно. С одной стороны распределяется нагрузка, с другой стороны в 2 раза увеличивается шанс, что или один или второй сервак подохнет по какой то причине.
Если берется простой дедикейт, то имхо лучше отдельно цельные сиджи разносить, чем разбивать по кускам.
цитата
19/06/09 в 00:32
color
а нафиг там бэкэнд вообще?
если скрипты на пхп, nginx сам прекрасно со всем справляется.
цитата
19/06/09 в 00:39
vlad3d
короче пробовать надо
с учетом всего вышесказанного
ясно.
цитата
19/06/09 в 00:50
Dr.Syshalt
color писал:
если скрипты на пхп, nginx сам прекрасно со всем справляется.
...да в принципе и апач, над которым поработали и настроили, должен не хуже бы справиться без всякого нгинкса. Есть желающие проэкспериментировать? ;) Сделаю бесплатно, чисто интереса ради. Просто нету под рукой сервера с нагрузкой такой, что действительно надо попотеть, чтобы запыхтело
цитата
19/06/09 в 01:38
allendale
Dr.Syshalt писал:
...да в принципе и апач, над которым поработали и настроили, должен не хуже бы справиться без всякого нгинкса. Есть желающие проэкспериментировать? ;) Сделаю бесплатно, чисто интереса ради.Просто нету под рукой сервера с нагрузкой такой, что действительно надо попотеть, чтобы запыхтело
Оффтопик:
Когда мы потеряем dlk, я знаю кто займёт его место
PS. Смотреть в топ. выкинуть mysql, поставить dtr. нагрузка должна значительно уменьшиться....
цитата
19/06/09 в 01:58
Woland
Цитата:
Когда мы потеряем dlk, я знаю кто займёт его место
Оффтопик:
dlk, он как чёба - пока сам не потеряется никто его потерять не сможет, по моему
Цитата:
выкинуть mysql, поставить dtr. нагрузка должна значительно уменьшиться....
У меня прощание с 18-20 (точно не помню) стримами на подобном сервере с мелкими сиджами снизило нагрузку втрое минимум, это при том, что тумбы все были уже сграбленные и отротированные. Стрим, имхо, самый тяжёлый из распространённых сиджевых скриптов в случае, если сиджей на серваке много (>15) (это не значит, что стрим плохой, просто юзать его при наличии множества мелких сиджей - не совсем рационально).
цитата
19/06/09 в 02:14
W
Woland писал:
Оффтопик:
dlk, он как чёба - пока сам не потеряется никто его потерять не сможет, по моему
Оффтопик:
Он как летун. dlk незаменимый
цитата
19/06/09 в 02:48
Dr.Syshalt
allendale писал:
Оффтопик:
Когда мы потеряем dlk, я знаю кто займёт его место
Ты сам пробовал апач с другим mpm кроме preforkа?
цитата
19/06/09 в 10:33
Mike Fox
Woland писал:
У меня прощание с 18-20 (точно не помню) стримами на подобном сервере с мелкими сиджами снизило нагрузку втрое минимум, это при том, что тумбы все были уже сграбленные и отротированные. Стрим, имхо, самый тяжёлый из распространённых сиджевых скриптов в случае, если сиджей на серваке много (>15) (это не значит, что стрим плохой, просто юзать его при наличии множества мелких сиджей - не совсем рационально).
со стримами нужно обязательно тюнить мускуль, иначе это как на автобусе проехать квотер за 12 секунд. очень часто мускуль с дефолтными настройками упирается в диск и тп
цитата
19/06/09 в 10:53
Well
второй дедик лучше взять ИМХО... я так и сделал когда сервак пару раз лег
цитата
19/06/09 в 15:54
PistoGanza
Влад, по-моему, ты все-таки несколько перестраховываешься ;)
На твоем сервере запас производительности еще приличный. Мускуль оттюнен. Памяти сводобной достаточно + память выделенная под кэш фс. Своппинга нет и в помине. Нагрузка на диски совсем не большая.
Единственное что ЛА подскакивает когда запускается пачка кронов. Тут тебе поможет совет приведенный выше - запускать их последовательно.
цитата
19/06/09 в 18:42
dlk44
Dr.Syshalt писал:
...да в принципе и апач, над которым поработали и настроили, должен не хуже бы справиться без всякого нгинкса. Есть желающие проэкспериментировать? ;) Сделаю бесплатно, чисто интереса ради. Просто нету под рукой сервера с нагрузкой такой, что действительно надо попотеть, чтобы запыхтело
Да ты из конфига Апача опубликуй те места которые настроил - а я у себя попробую что это даст.
цитата
19/06/09 в 19:01
El Nino
действительно а апач у тебя с 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)
короче вариантов решения и оптимизации масса
цитата
19/06/09 в 19:04
dlk44
Stek писал:
в рунете не достаточно насмотрелся ошибок nginxa о связи с бакендом ?
Ну у меня были ошибки Апач не успевал данные отдать нгинксу - увеличил таймаут в нгинксе все стало OK.
цитата
19/06/09 в 19:04
El Nino
PistoGanza писал:
Влад, по-моему, ты все-таки несколько перестраховываешься ;)
На твоем сервере запас производительности еще приличный. Мускуль оттюнен. Памяти сводобной достаточно + память выделенная под кэш фс. Своппинга нет и в помине. Нагрузка на диски совсем не большая.
Единственное что ЛА подскакивает когда запускается пачка кронов. Тут тебе поможет совет приведенный выше - запускать их последовательно.
кроны кстати надо по времени разнести и все станет лучше
как вариант можно в кроне запускать скрипт а уже в скрипте последовательно запускать все задачи крона
тогда не будет параллельных тяжелых процессов
цитата
19/06/09 в 19:53
Dr.Syshalt
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 не держал, вот и весь "тьюнинг". И канал там забивался постоянно, но ни разу не было, чтобы оно упало, аптайм в сотни дней был (перезагружал только по апдейтам кернела, а то бы все несколько лет простоял)
У меня даж мысль появилась, что хостер просто разводит на добавление памяти
цитата
19/06/09 в 22:35
deSilva
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 - за гибкость конфигурирования надо чем-то расплачиваться, вот и расплачиваемся производительностью.
цитата
19/06/09 в 23:17
El Nino
давайте не будем столь однозначно делать выводы на счет MPM
потому что везде есть свои ньюансы
вот человеку вводная инфа по сравнению MPM моделей
http://phpsuxx.blogspot.com/2008/01/apache2-prefork-vs-worker.html
пусть почитает ознакомится
никто же не знает чего творится на его сервере...
доками тыкать лично меня не надо, я знаю где они находятся, однозначно все равно трудно кого либо будет убедить в стабильности каждой модели пока не попробуешь сам
в общем оптимизация сервера в твоих руках
на 6 мбитах проблема надумана безусловно
Стр.
« первая
<
1
,
2
,
3
>
последняя »
Новая тема
Ответить
Эта страница в полной версии