Оптимизация веб-сервера (инструкция)

[chesser]

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

А у меня вопросы:
1) что там по файловым системам? под веб-сервер что оптимально сейчас? на большие файлы и/или быстрое чтение XFS, на остальное ext3/4 ? еще есть(был) рейзер, но я ее не крутил.
2) монтирование ФС - какие параметры сильно влияют на производительность? Например, noatime должно убыстрять фс, но наверно возможны сюрпризы от софта, работающего с atime (а еще есть relatime)
3) и вообще интересуют советы по настройке именно ОС: /etc/sysctl.conf, /etc/sysconfig, и тд
4) средства диагностики, мониторинга, профайлинга какие? из RRD инструментов munin'а имхо достаточно, а nagios, zabbix - лишнее, или есть смысл в них при 1 сервере?

[medar]

В mysql можно добавить:
Вычисление ситуаций, когда надо переходить на InnoDB (характер запросов, количество локов таблиц).
Ибо это, бывает, решает проблемы.

nagios, zabbix - имхо, лишнее.

[Armen]

chesser молодец! Сейчас редко встретишь людей готовых толково делиться своими знаниями публично.
Можно написать еще про ротацию логов. Если в nginx не отключить их, то запись в гиговые логи прилично досаждают.

[chesser]

про myisam -> innodb добавил. А вообще про оптимизацию БД можно книги писать, все в чеклист не влезет. Там у меня ссылка есть на англоязычный список типсов

про logrotate тоже добавил, у меня была подобная проблема, когда вдруг сервер "встал" - место кончилось из-за /var/log/btmp - он достиг каких-то гигантских размеров. Настройка logrotate вернула в правильное русло

а еще? делитесь своими секретами

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

а навеяно это было топиком про тормоза wordpress

[MyName]

по ФС есть ещё ZFS вроде шустрая но не поручусь.
воде на FreeBsd она поддерживается лучше чем на линуксе.

/var/logs полезно курить помоему

апачь ты не любишь но учитывая что это фак имхо было бы полезно добавить что-то и про него.
например что полезно курить эрор лог апача в /var/logs искать там ругань на MaxClient и крутить соответствующую переменную в настройках.

в принцепе что-то подобное актуально и для php-fpm тока кого там искать надо не помню.

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

кстати ещё полезно всякие модули выкидывать из php будь то php-fpm или модуль в апаче (тогда и из него). проверенно на практике так сказать несколько серверов было с большой нагрузкой там php с включенными лишними модулями время от времени сервак в swap загонял после их выкидывания сервак стал работать нормально несмотря на ~600 процессов апача одновременно крутящихся и активно использующихся и всего 2 GB ram.

весьма кстати неплохой + к производительности сервака SSD дает при условии активной нагрузки на диск.
Также существенный момент если приложение работает с файлами оптимизация этой части. например если при каждом заходе дергается большой файл какой-то лучше его разорвать на 100-1000 мелких и их дергать LA очень сильно снижается

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

ззы
страшно... ещё 1 человек стал добрыми делами заниматся

[chesser]

ZFS придумали для соляриса, ну потом растеклось по всем ос. Тоже с ней не работал(видел один раз вдалеке), и думаю не скоро еще попробую, темная лошадка для меня. А тестить ее ради спорт. интереса пока нет времени.

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

добавил: анализ /var/logs и отключение лишних модулей php(тоже всегда ставлю минимум)

по Ngnix имхо было бы неплохо немного пройтись по настройкам

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

на счет ssd - согласен, но от него всегда будет только плюс, тоже самое можно советовать памяти больше, проц сильнее. Это уже scale up, т.е. вертикальное масштабирование. Короче надо представить, что ssd нельзя поставить ...ну обычно в аську кто-нить стучит, мол: "глянь сервер плиз, тормозит, даю 100 баксов" - тут не до ssd обычно

спасибо за коммент

[MyName]

кстати вот ещё заметил
gzip_static on (ngx_http_gzip_static_module); «for i in `find ./* -type f -name ‘*.js’`; do echo $i; gzip -c -9 $i > $i.gz; done;»
если мне не изменяет мой скалероз тут задается степень сжатия. так вот с этм параметром имхо стоит игратся главный вопрос во что упирается сервак. если в кпу имхо лучше вообще сжатие отключить. т.к. сжатие = нагрузка на проц. а вот польза от максимальной степени сжатия не так очевидна. будет выигрыш если не путаю в памяти и нагрузке на канал (могу ошибаться с нгникс не так чтоб сильно знаком..)

кстати тюнинг ядра какие нибудь общие рекомендации будут? хотя тут общие по моему особо и не подходят.. во freebsd одно в linux другое..

и по майскуль оптимизации если сервак опять таки упирается в рам крутить тотже mysqltuner.pl надо очень осторожно нередко бывает для сервака выгоднее минимизировать кеши у mysql и отдать ram под процессы php-cgi или httpd. как пример подобное актуально при залезании в swap.

вообще оптимизация сервака даже самая общая должна начинатся с вопроса "а что же нам жить мешает?" и дальше уже копать в ту сторону. у меня например как-то чаще все упирается в ram и hdd а вот в cpu почти никогда не упирался.

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

спасибо за коммент

рад что был полезен

[chesser]

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

кстати вот ещё заметил
gzip_static on (ngx_http_gzip_static_module); «for i in `find ./* -type f -name ‘*.js’`; do echo $i; gzip -c -9 $i > $i.gz; done;»
если мне не изменяет мой скалероз тут задается степень сжатия. так вот с этм параметром имхо стоит игратся главный вопрос во что упирается сервак. если в кпу имхо лучше вообще сжатие отключить. т.к. сжатие = нагрузка на проц. а вот польза от максимальной степени сжатия не так очевидна. будет выигрыш если не путаю в памяти и нагрузке на канал (могу ошибаться с нгникс не так чтоб сильно знаком..)

здесь про другое речь, есть два разных модуля:
ngx_http_gzip_module - ты про этот говоришь, оптимально ставить степень сжатия 5, если проц имеет запас для этого
ngx_http_gzip_static_module - это типа кеша зипованных файлов. Например, если в папке лежит script.js и script.js.gz - то nginx сразу же отдаст второй файл, и жать уже ничего не нужно, т.к. все сжато заранее.

оба модуля могут работать одновременно, т.е. если .gz нет, то файл сжимается обычным nginx gzip'ом динамически. К сожалению, nginx не умеет сам делать/обновлять статические gz файлы по мере надобности, поэтому надо самим об этом думать, crontab поможет например

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

кстати тюнинг ядра какие нибудь общие рекомендации будут? хотя тут общие по моему особо и не подходят.. во freebsd одно в linux другое..

ядра ОС тюнить я сам не очень спец. Это уже больше сисадминское занятие.
Иногда полезно поднять кол-во открытых файл-хендлеров.

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

и по майскуль оптимизации если сервак опять таки упирается в рам крутить тотже mysqltuner.pl надо очень осторожно нередко бывает для сервака выгоднее минимизировать кеши у mysql и отдать ram под процессы php-cgi или httpd. как пример подобное актуально при залезании в swap.

вообще оптимизация сервака даже самая общая должна начинатся с вопроса "а что же нам жить мешает?" и дальше уже копать в ту сторону. у меня например как-то чаще все упирается в ram и hdd а вот в cpu почти никогда не упирался.

не всегда такой вопрос. Часто все работает "вроде нормально", но если выполнить несколько элементарных вещей, то производительность увеличивается в неск. раз и почти на ровном месте. Обычно это различные формы кеширования и установка nginx. Обычно такая оптимизация равна переходу на следующий тарифный план, в случае впс

[MyName]

спасибо за развернутый ответ по gzip

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

ядра ОС тюнить я сам не очень спец. Это уже больше сисадминское занятие.
Иногда полезно поднять кол-во открытых файл-хендлеров.

вот блин а я надеялся ибо сам тоже не спец

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

не всегда такой вопрос. Часто все работает "вроде нормально", но если выполнить несколько элементарных вещей, то производительность увеличивается в неск. раз и почти на ровном месте. Обычно это различные формы кеширования и установка nginx. Обычно такая оптимизация равна переходу на следующий тарифный план, в случае впс

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

недавно например на атом утрамбовал 2 cj 50к трафа в сумме, сутру, 10 wp штуки 4 из которых под трафиком 1.2к в час каждый ну и так кучу фигни по мелочи оно даже не падает правда чутка своп юзает иногда. но ssd спасает

//вот написал и подумал.. а фигли я туда Ngnix не поставил.. прощай swap

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