Пользователь
0,0
рейтинг
20 сентября 2009 в 17:47

Администрирование → Сервер на стероидах: FreeBSD, nginx, MySQL, PostgreSQL, PHP и многое другое

Нравится мне эта картинка, у меня, вот никогда такие красивые графики в какти не получались =(

Введение


С момента написания мной предыдущей статьи по оптимизации этой связки прошло довольно много времени. Тот многострадальный Pentium 4 c 512Мб памяти, обслуживающий одновременно до тысячи человек на форуме и до 150,000 пиров на трекере уже давно покоится на какой-нить немецкой, свалке, а клуб сменил уже не один сервер. Всё сказанное в ней всё ещё остаётся актуальным, однако есть вещи которые стоит добавить.
Статья большая, так что будет поделена на логические блоки:

0. Зачем вообще что-то оптимизировать?
  
1. Оптимизация ОС (FreeBSD)
  1.1 Переход на 7.х 
  1.2 Переход на 7.2
  1.3 Переход на amd64
  1.4 Разгрузка сетевой подсистемы
  1.5 FreeBSD и большое кол-во файлов
  1.6 Softupdates, gjournal и mount options
  
2. Оптимизация фронтенда (nginx)
  2.1 Accept Filters
  2.2 Кеширование
  2.3 AIO
  
3. Оптимизация бэкенда
  3.1 APC
  3.1.1 APC locking
  3.1.2 APC hints
  3.1.3 APC fragmentation
  3.2 PHP 5.3
  
4. Оптимизация базы данных
  4.1 MySQL 
  4.1.1 Переход на 5.1
  4.1.2 Переход на InnoDB
  4.1.3 Встроеный кеш MySQL - Query Cache
  4.1.4 Индексы
  
4.2 PostgreSQL
  4.2.1 Индексы
  4.2.2 pgBouncer и другие.
  4.2.3 pgFouine
  
4.3 Разгрузка базы данных
  4.3.1 SphinxQL
  4.3.2 Не-RDBMS хранилище
  4.4 Кодировки
  4.5 Асинхронность
  
Приложение. Мелочи.
  1. SSHGuard или альтернатива.
  2. xtrabackup
  3. Перенос почты на другой хост
  4. Интеграция со сторонним ПО
  5. Мониторинг
  
 6. Минусы оптимизации


0. Зачем вообще что-то оптимизировать?


Вообще расти можно:
  • Scale up (Наращивать железо)
  • Scale out (Увеличивать количество фронтендов/машин в middle tier)
  • Оптимизируя

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

1. Оптимизация ОС (FreeBSD)


1.1 Переход на 7.х


Что же мы получим при переходе на новую версию FreeBSD?
По мне самое главное это:
Новый ULE 3.0 Scheduler и jemalloc весьма полезны на многоядерных (>=4) системах.
MSI (Message Signaled Interrupts) — они же часто упоминаются в драйверах как Fast Interupts.

Так что если у вас есть legacy 6.x система, которая начинает прогибаться под нагрузкой, возможно стоит перевести её на 7.х.


1.2 Переход на 7.2


Superpages, увеличенный KVA, оптимизированные по-дефолту sysctl'и. Всё это вы получите абсолютно бесплатно просто перейдя на последний релиз ОС.

Прогресс тоже не стоит на месте и вот уже FreeBSD 8.0 готовится к выходу, там нам обещают дальнейшее увеличение производительности. В качестве подтверждения стабильности www.FreeBSD.org был переведён на FreeBSD-CURRENT ещё во времена первых beta-версий. Так что на staging машинах можно её уже начинать гонять.


1.3 Переход на amd64


Переходя на amd64 вы дополнительно получите гиганские размеры KVA и Shared Mem >2Gb. Однако это далеко не самое главное...

Заметьте, что 4 Gb памяти в 2009 году уже во всю ставят на ноутбуки, и ставить столько на сервер с БД довольно смешно. Конечно, для маленькой БД это нормально, но что делать когда она разрастётся и перестанет влезать в память? C i386 ОС доставить ещё памяти будет проблематично, ибо PAE это отдельный глюк. Да и INT64 уже давно много где используется и даёт прирост производительности таким приложениям как, например, базы данных и OpenSSL. (Если у кого есть линки на адекватные бенчмарки "***SQL i686 vs amd64" — кидайте в комменты).


1.4 Разгрузка сетевой подсистемы


Тут во FreeBSD не то что поле, а целый полигон для испытаний.
Всю оптимизацию можно разделить на 2 части: Тюнинг параметров ifconfig и настроек sysctl.conf/loader.conf, давайте в таком порядке и пойдём.
Для начала нужно посмотреть на что наши сетевухи вообще способны, для этого можно воспользоваться такой командой:
# ifconfig -m
capabilities=399b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_UCAST,WOL_MCAST,WOL_MAGIC>

В случае если у вас хорошая сетевуха класса em (Intel Gigabit) / bge (Broadcom Gigabit) можно попробовать опции ifconfig:
  • tso (tso4, tso6) — TCP Segent Offloading
  • lro — Large Recive Offload
  • txcsum, rxcsum — RX / TX Checksum Offload
  • link0, link1, link2 — зависят от драйвера, надо смотреть его код. Иногда включают некоторые оптимизации, иногда просто переключает сетевуху в MASTER на Gigabit линках.

Также, на em сетевухах и многоядерных процах можно попробовать драйверы от Яндекса, которые осуществляют обработку пакетов в несколько потоков. Так же очень много всего про тюнинг сетевой подсистемы можно прочитать на nag.ru

Если же у вас третьесортная сетевуха (re/rl/sk/nfe...), то вышеописанные опции могут работать неправильно и приводить к зависанию сервера, так что лучше остановиться на polling'e.

Ну и напоследок рекомендую всем посмотреть обновлённую версию тюнинга FreeBSD 7 «по Сысоеву» и мой лист sysctl'ей с комментариями.


1.5 FreeBSD и большое кол-во файлов


Во FreeBSD есть прекрасная технология кеширования имён файлов в директориии. Так, если у вас в одной директории находится множество файлов, то намного лучше использовать поиск по хеш таблице, нежели постоянно пробегать по всему дереву вширь/вглубь в поисках нужного файла. Однако, макс. кол-во памяти выделенное под dirhash (так называется эта технология) ограничена vfs.ufs.dirhash_maxmem и по-умолчанию составляет, вроде, 2Мб, что весьма мало. Рекомендуется увеличивать память до тех пор пока vfs.ufs.dirhash_mem не перестанет упираться в «потолок».


1.6 Softupdates, gjournal и mount options


Новые терабайтные винты просто шикарны — стоят дешево, да и производительность у них просто касс. Однако, есть один нюанс: когда в датацентре отрубят электричество, то fsck таких терабайтников может занять не один час. Решить эту проблему можно используя softupdates или же прикрутить к системе журналирование через gjournal. Что именно, решать вам.
Пара советов по журналированию: чтобы не потерять производительность, лучше журнальный раздел оправить на отдельный диск, а чтобы не ловить паники из-за его переполнения, лучше сделать раздел журнала побольше (например, RAM+swap).
Если же у вас есть raid с BPU, или вам просто нечего терять, то можно в /etc/fstab добавлять опцию async. А такую опцию как noatime можно практически без опаски порекомендовать всем. (читать комментарий пользователя giner вот тут)


2. Оптимизация фронтенда (nginx)


На самом деле, я крайне против чрезмерной и/или преждевременной оптимизации, к коим относится оптимизация фронтенда. Обычно на веб проектах, где nginx занимается не только статикой, он потребляет 1%-5% CPU в зависимости от характера его использования, остальное же кушает php.
Однако, оптимизация конфига nginx может повлиять на общий response time сайта, так что есть моменты о которых стоит поговорить.
Из стандартных оптимизаций могу порекомендовать
 reset_timedout_connection  on;
 sendfile                   on;
 tcp_nopush                 on;
 tcp_nodelay                on;

Ну и поиграться с количеством воркеров, а не просто ставить их по кол-ву CPU/Винтов. Также рекомендую всем ознакомится с этим документом и темой Nginx best-practices на Serverfault, очень вероятно, что вы узнаете что-то новое.



2.1 Accept Filters


Во FreeBSD имеется технология, позволяющая передавать пакет от ядра к процессу только в случае прихода 1) каких либо данных 2) валидного http запроса. Технология эта называется accept filters. Такие фильтры помогут как разгрузить сервер в случае большого кол-ва соединений, так и немного защитить от DDoS'a (Хотя со вторым лучше справляется ngx_http_limit_req_module, о котором уже не раз писалось на хабре)
Чтобы включить обработку соединений с использованием фильтров, нужно для начала загрузить модуль ядра:
#ls /boot/kernel/|grep acc
   accf_data.ko
   accf_http.ko
#kldload accf_http

Далее в конфиге nginx.conf включить фильтр httpready:
listen 80 default accept_filter=httpready;


2.2 Кеширование


В nginx имеется очень гибкая система кеширования ответов, как от fastcgi, так и от proxy backend'ов. Я думаю у каждого прочитавшего документацию в голове сразу возникло несколько сценариев применения кеширования в своём проекте. Я могу дать только общие советы:
Не дай Бог у вас rss отдаётся через php скрипт. Если так, то спокойно можно кешировать ответ на 3-5 минут.
Думаю почти всю версию сайта для гостей можно запихнуть в кеш тоже минут на 5 (ну если конечно у вас не новостной сайт)

Кроме серверного кеша существует ещё и кеш клиентский. Я бы рекомендовал на всю статику повесить expire в месяц:
    
        location ~* \.(jpg|jpeg|gif|png)$ {
    	   root   /var/nnm-club;
    	   expires      30d;
        }

2.3 AIO


Про введение AIO в nginx уже писали на хабре, там же имеются довольно интересные обсуждения в комментах. Вкратце, AIO полезен на весьма специфичных нагрузках, а так же помогает сохранить response time при уменьшении количества воркеров.
Для использования aio нужно подгрузить модуь ядра aio.ko:
#kldload aio
а затем включить aio и sendfile в nginx.conf
 
 sendfile        on;
 aio             sendfile;

Новые версии nginx позволяют использовать aio вместе с sendfile. По поводу такой конфигурации в документации сказано:
В такой конфигурации используется флаг SF_NODISKIO и sendfile() не блокируется на диске, а сообщает об отсутствии данных в памяти, после чего nginx инициирует асинхронную подгрузку данных, читая только один байт. При этом ядро FreeBSD подгружает в память первые 128K файла, однако при последующих чтениях файл подгружается частями только по 16K. Поэтому этот режим лучше применять для раздачи небольших, до 128K, файлов.

Патч для FreeBSD, для решения этой проблемы тут, возможно со временем он войдёт в -CURRENT и будет портирован в 8.0 и 7.х


3. Оптимизация бэкенда


Тут особо много мне расскажешь, у java, например, есть волшебные строки из серии "-Xms768m -Xmx1280m -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+UseCompressedOops -Djava.net.preferIPv4Stack=true -XX:+DoEscapeAnalysis", которые способен понять только наш java-программер, а у PHP 50% оптимизации деает кеширование opcode, остальной прирост наблюдается от кеширования ответов от БД. Так что эта часть топика будет весьма скупой.

3.1 APC


Про оптимизацию APC рассказывали разработчики Facebook. Очень рекомендую почитать, если будет время.

3.1.1 APC locking


Старый File Locking, это именно тот «тормоз», из-за которого вместо APC начинают использовать eAccelerator. Так, что дефолтный locking часто рекомендуют менять на spinlock или pthread mutex. Насколько я помню, pthread mutex стал дефолтным начиная с 3.0.16, так что, если у вас есть сервера со старым APC рекомендую его обновить.

3.1.2 APC hints


Если у вас много .php файлов или вы много кешируете в APC user cache, то весьма вероятно вам придётся поднимать значения
apc.num_files_hint и apc.user_entries_hint соответственно в php.ini. Эти значения отвечают за размеры hash таблиц APC (на самом деле они ещё удваиваются перед применением), а мы знаем что хеш таблицы работают весьма плохо при load factor >= 0.75


3.1.3 APC fragmentation


Фрагментация в APC — это такая штука, из-за которой этот самый кеш хочется взять, скомкать и выкинуть в окно. APC не являтеся заменой нормальному key-value по причине его неспособности удалять автоматом записи по TTL или LRU. То есть, нету никакого GC и записи попавшие в кеш от туда могут уйти только в двух случаях:
  • Когда к ним обратились после истечения их ttl
  • Вся память кончилась и APC прибег к экстренной мере — сброс всего кеша целиком.

Суммируя, можно сказать: Высокая фрагментация является признаком того, что вы используете APC не по назначению.
Тут нужно добавить заметку, судя по комментам тут, в 3.1.х очень многое поправили в плане аллокации памяти, однако судя по этому, 3.1.х работает не у всех.



3.2 PHP 5.3


Тут всё кажется простым — обновляем PHP, получаем прирост производительности. Однако, посмотрев на список deprecated функций в 5.3 можно ужаснутся, благо они пока ещё работают.
Несмотря на всю простоту, думаю, переход от 5.2 до 5.3 будет ойойой каким долгим, особенно в продакшне.


4. Оптимизация базы данных


На самом деле лучшими оптимизациями БД у нас в клубе признаны:
  • Не использование RDBMS вообще (sphinxsearch)
  • Не использование базы (кеширование)
  • Batch запросы (where in (...), batch insert/update)
  • Ассинхронная работа с БД (memcacheQ, apacheMQ, AQMP, crontab)

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


4.1 MySQL


Мануалов в инете по оптимизации MySQL довольно много, есть грамотные, есть не очень. В любом случае, за время жизни любого веб-проекта его база успеет упереться и в память, и в диск, и может даже в процессор, так что простыми howto не обойтись, придётся смотреть конференции, учится пользоваться профайлерами(oprofile, systemtap, dtrace) и использовать большое кол-во дополнительного ПО. Иными словами, не только понимать, что такое индексы, сортировки и группировки, но так же понимать как MySQL их использует внутри, знать что такое EXPLAIN, Query cache, преимущества и недостатки различных storage engine'ов, в общем, быть 100% DBA для своего проекта.
Далее я опишу способы которые помогут с минимальными изменениями кода (а то и вовсе без них), оптимизировать MySQL.
Как я уже говорил в предыдущей части, 50% тюнинга MySQL можно провести в полуавтоматическом режиме всего двумя утилитами:

4.1.1 Переход на 5.1


Переход на 5.1 приносит множество бонусов, мне конкретно были интересны:
  • Оптимизация оптимизатора (особенно GROUP BY)
  • InnoDB plugin
  • Partitioning
  • Row based replication

Всё это может прибавить производительности, так что на 5.1 перелезать стоит. По поводу шума вокруг того что 5.1 не стабильна, то всё это уже не актуально, да и изначально было слишком раздуто (если у кого есть какие противопоказания или bad expirience перехода на 5.1 — прошу в комменты).
Самые экстрималы, конечно, уже давно тестируют 5.4, там говорят производительность очень хорошо подняли (не без помощи патчей от Гугла и Percona, я думаю). Но до продакшна 5.4 ещё далеко.


4.1.2 Переход на InnoDB


Вот скажите, если у вас используется MyISAM, то почему именно он? Я вообще не понимаю как может продакшн сервер жить на MyISAM (хотя, говорят такие существуют), где нет транзакций (если сервер упадёт во время большого UPDATE, то половина данных будет изменена, а половина нет), есть TABLE LOCK (во время записи в таблицу она блокируется на чтение и vice vresa), а REPAIR после пропадания электричества в датацентре может занимать десятки часов. Единственное, что спасает MyISAM — это наличие Fulltext Index, но даже он вряд ли может конкурировать по качеству и скорости со sphinxsearch.


Да, у InnoDB есть свои недостатки (deadlock'и, бОльшие по размеру индексы, отсутствие FTS), но бонусов, имхо, в разы больше: Во-первых, InnoDB полностью ACID-совместим, а значит любая операция, даже такая как дамп базы данных, может быть произведена в одну транзакцию (опция mysqldump --single-transaction), а во-вторых, он имеет row-level locking (против TABLE LOCK у myisam), это означает, что данные могут одновременно и читаться и писаться в несколько потоков не блокируя друг друга.
Опять же, люди совсем озабоченные производительностью сердца своего стартапа могут использовать XtraDB, говорят оно сильно помогает на I/O-bound workload'ах.


4.1.3 Встроеный кеш MySQL — Query Cache


Query Cache — это одна из самых «недопонимаемых» частей MySQL. Многие его ставят в 512Mb и думают, что «щас всё залетает», многие его отключают вообще потому, что «всёравно не работает». Попытаюсь пролить свет на значение этого параметра. Начну с того, что больше, в данном случае, не лучше, так что задирать его не стоит. Далее, надо уточнить, что Query Cache — это полностью не распараллеленная подсистема, так что на кол-ве процессоров >=8 её лучше отключать, ибо будет только тормозить. Ну и последнее, но не самое бесполезное — суть Query Cache в том, что его содержимое, относящееся к какой либо таблице, полностью сбрасывается при любом изменении этой самой таблицы. Тоесть, фактически, Query Cache даёт прирост производительности только на грамотно нормализованных таблицах.
Подробнее о QC можно прочитать тут.


4.1.4 Индексы


Как отсутствие индекса вредно для SELECT'a, так и лишние индексы вредны для INSERT/UPDATE. Часто бывает так, что старый, когда-то сделанный индекс, может жить в базе не один год, занимая драгоценную память и замедляя изменения данных. Тут приходит на помощь простенький SQL запрос. Полезно? Множество подобных tips'ов можно найти тут.



4.2 PostgreSQL


Для меня Postgres остаётся довольно странной системой: с одной стороны это база Enterprise класса и на нём бегает Skype, с другой настройки по умолчанию такие, что он может запустится даже на моём мобильнике. В общем надо тюнить, а тюнить тут можно практически всё. Из возможных почти 200 параметров, за тюнинг отвечают основные 45 =)
Кстати, что ещё поразило, так это то, что при закомменчивании строки в конфиге, PostgreSQL не сбрасывает её на «дефолт», а использует ту, что «запомнил»… Показалось?
По тюнингу Postgres в инете много всего (часть мануалов устарела, так что обращайте внимание на дату публикации и ключевое слово vacuum_mem, которое заменено на maintenance_mem в новых версиях). Есть что-то типа FAQ: вскользь о главном, есть очень глубокомысленные трактаты для продвинутых администраторов БД… Я расскажу лишь основы которые помогут проекту продержаться на ногах, пока админ с програмером ищут квалифицированного DBA.


4.2.1 Индексы


Тут у некоторых может возникнуть справедливый вопрос: почему, мол, у MySQL индексы были на последнем месте, а у PosgreSQL на первом? Всё просто, ибо возможности его в этом плане намного выше, чем у MySQL. B-tree, hash, GiST, GIN, а также multicolumn, partial и indexes on expressions: во всём этом должен разбираться человек который программирует под PostgerSQL. И не просто знать, что такие существуют, а понимать, в каких случаях нужно использовать одни типы индексов, а в каких другие.
Полезные для мониторинга SQL-запросы (в том числе и статистику по индексам) можно найти тут.


4.2.2 pgBouncer и другие.


pgBouncer (или его альтернатива) — первое, что должно быть установлено на сервере с базой данных. Я уже насмотрелся на cacti-графики показывающие десятикратное падение нагрузки от простой установки менеджера соединений. Если пулер соединений у вас не установлен, то на каждое соединение с базой у вас запускается отдельный процесс, далее этот процесс отъедает, как минимум, work_mem оперативки и начинает бороться за CPU и жесткий диск с себе подобными выполняя SQL запрос. Всё бы хорошо, но вот когда количество таких процессов зашкаливает за 200-500 серверу, даже очень мощному, становится туго. Очень туго. pgBouncer нас от этого спасает.
Также список полезных или даже незаменимых приложений для работы с PostgreSQL можно найти на сайте postgresqlrussia.org.


4.2.3 pgFouine


pgFouine как раз одна из таких незаменимых программ. Это очень продвинутый аналог mysqlsla на php. В комплекте с Playr (реплэйер продакшн логов) она позволяет проводить оптимизацию запросов на staging серверах в практически «боевых» условиях.


4.3 Разгрузка базы данных


Как я уже говорил, лучший способ оптимизировать работу БД и увеличить её производительность — это обращаться к ней как можно реже.


4.3.1 SphinxQL


В прошлой статье я говорил, про то что мы ввели поиск на основе sphinxsearch. Но не все смогут перерыть тысячи строк кода, чтобы начать использовать SphinxAPI, а потом потратить ещё 1-2 итерации на тестирование и отлов багов. Проблема решилась очень элегантно: SphinxSearch научился притворяться MySQL сервером, то есть для того чтобы начать его использовать необходимо лишь создать sphinx.conf, создать записи для indexer'a в cron'e и переключить поиск на другую «как бы mysql» базу. Есть вероятность, что дальнейшей правки кода не понадобиться.
Что вы получаете при переходе на сфинкс? Кроме улучшений скорости и качества поиска, вы сможете избавиться от MyISAM и его FTS, ну и, что очень интересно, так это придумать новые применения вашему поиску, мы вот, объединили поиск с RSS, что оказалось весьма удобным.
А вот и пара примеров, в которых можно выиграть от наличия sphinxsearch (придумано почти с ходу, так что сильно не бейте):

Пример 1: Я давно жду Starcraft 2, я всегда могу добавить в Google Reader RSS вида: rss.php?q=«starcraft 2» и увидеть все сообщения в которых его обсуждают. Так же, я, как участник форума, хочу видеть все посты где упоминается мой ник. Это тоже не проблема, надо всего лишь подправить урл.

Пример 1.5: Пользователь зашёл на сайт увидел строку поиска, ввёл запрос, нечего не нашлось, но появилась ссылка «Подписаться на этот поиск», со ссылкой на RSS для этого запроса. Так просто пользователь от вас не уйдёт =))

Пример 2: Я хочу найти фильм 21, или, не дай Бог, фильм 9 — MySQL не самоубийца, он такой запрос просто откинет, посетовав на то, что ft_min_word_len больше, чем длинна запроса. Сфинкс практически мгновенно вернёт результат в виде «Двадцать Одно / 21», а во втором случае даже даст выбор между «Район №9 / District 9» и «Девять / 9».



4.3.2 Не-RDBMS хранилище


Существует очень много мест в проекте, где можно не использовать реляционную базу данных. Достаточно простого key-value хранилища. Благо таких сейчас хватает.
Также есть весьма интересные проекты как, например, Hive (Data Warehouse с SQL-подобным QL и бекендом в виде Hadoop). В общем с хранилищем данных, можно ой как поэкспериментировать, не одним Oracle'ом (MySQL'ем, PostgreSQL'ем, FoxPro, нужное подчеркнуть) живы.
Также key-value БД из-за своей скорости используются для кешиорвание выборок из реляционных баз. По поводу самого кеширования: после пролистывания презентации, просмотра видео и прочтения полного текста доклада из блога Андрея Смирнова, мне практически нечего добавить. Лишь пара советов:
Если у вас действительно большой проект на PHP, то не забываете про возможность opcode cache хранить custom данные. В нём можно хранить самые часто используемые глобальные переменные: во-первых их не много и они маленькие, так что памяти кушать они будут совсем чуть-чуть, во-вторых скорость выборки будет выше, чем из memcached находящегося на соседней машине. Ну и самое интересное: в больших проектах бывали случаи когда блок глобальных переменных записывали на какую-то одну машину из memcached-фермы, так как эти переменные юзают все бэкенды, то трафик на эту машину возрастал до неприличных размеров и машинка начинала очень сильно тормозить, а вместе с ней и все бэкенды. Выходом из такой ситуации являлось бы либо хранение глобальных переменных в opcode cacher'e типа APC/eAccelerator, либо клонирование переменных на все сервера из memcached-фермы и внесение исключений в алгоритм consistency hashing'а.



4.4 Кодировки


Небольшая заметка по поводу кодировок:
UTF-8 хорош всем кроме одного — русский текст в нём занмает ровно в два раза больше места, так что иногда есть над чем задумываться перед тем как его использовать, если у вас целиком одноязычный контингент.


4.5 Асинхронность


На самом деле, далеко не всегда требуется синхронная обработка данных, довольно часто её можно заменить асинхронной.
Асинхронная обработка помогает 1) Улучшить время реакции сайта/приложения 2) Уменьшить нагрузку на сервер.
Если с первым всё понятно, то второе является следствием того, что batch запросы выполняются быстрее одиночных.
Асинхронность можно организовать по разному. В крупных проектах для этого используют очереди сообщений (ApacheMQ, RabbitMQ, ZeroMQ. Про AQMP уже несколько раз писалось на хабре), в мелких можно обойтись и cron'ом.


Приложение. Мелочи.


1. SSHGuard или альтернатива.


Кроме того, что это стандартная практика ставить анти-брутфорс для ssh, так это ещё и дополнительно помогает защитить сервер от резких всплесков Load Avarenge когда на него нападают совсем офигевшие боты и начинают брутфорсить пары логин-пасс десятками тысяч.


2. xtrabackup


LVM снапшоты — это тормоз. mysqldump — лочит таблицы и делает текстовые бэкапы, которые могут восстанавливаться неделями. Очень хорошим инструментом для бэкапа MySQL является xtrabackup от Percona. Сильно расписывать его не буду, ибо русская часть инета о нём наслышана. Вкратце, xtrabackup это инструмент, позволяющий проводить не блокирующий бинарный бэкап InnoDB/XtraDB таблиц и имеющий кучу настроек. Почему очень хороший, а не отличный? Поскольку самым лучшим инструментом, на мой взгляд, являются клоны в ZFS. Делаются мгновенно, а восстановление базы с них это просто изменение пути к файлам в конфиге мускула, да и при неудачном востановлении можно откатится обратно. Также с клонов можно восстанавливать систему целиком, например в случае неудачного апгрейда ядра.
А вообще, вроде, в 5.4 нам обещают встроеный online backup


3. Перенос почты на другой хост


Данная оптимизация кажется минорной, однако при большом кол-ве спама льющегося на сервер помогает сильно уменьшить трафик и спасти множество IOPs.


4. Интеграция со сторонним ПО


Как-то на хабре проскакивала статья про online игры, мол, для всего нужно использовать наиболее подходящие средства (кто-нибудь помнит как она называлась?). Так, например, для того, чтобы дать возможность пользователям обмениваться почтовыми сообщениями с вложениями, не нужно начинать писать PHP скрипт с бэкендами в виде БД/ФС, можно использовать для этого, то что в реальной жизни применяется для обмена текстовыми сообщениями — связку smtp/imap и написать к ним простенький адаптер. По аналогии, чат для пользователей можно организовать на основе jabber сервера с javascript клиентом, который вообще не будет грузить сервер. Нужно отмечать объекты на на карте? Тут легче лёгкого написать mashup с использованием Yandex/Google карт. Что интересно, так такие системы, написанные на основе адаптера к готовым продуктам зачастую очень хорошо масштабируются, по крайней мере, на порядки лучше, чем решения на PHP и MySQL.


5. Мониторинг


Нечего оптимизировать, если не знаешь текущего состояния. Метрики производительности, задержек, свободных ресурсов, всё это должно мониториться, логироваться и, желательно, рисоваться на графиках. Благо инструментов хватает: Nagios, Zabbix, Cacti, Munin....

Берите любой, ставьте на сервак(и) и наблюдайте за влиянием оптимизаций на нагрузку сервера. Также мониторинг поможет предвидеть появление проблем с производительностью.


6. Минусы оптимизации


Bleeding-edge он, ведь, не случайно так назван. Во время переезда клуба на новый сервер мы это почувствовали на своей шкуре, умудрившись найти баги практически во всём (APC1, APC2, MySQL, nginx, xbtt), благо OpenSource, что-то простое можно самим починить.


Вместо послесловия


Ну вот, вроде, и всё. Почти неделю печатал… Что осилил, то осилил, за кадром оставил ZFS, распределённые ФС, репликацию и шардинг, ибо это темы для отдельных постов. С грамматикой и пунктуацией у меня всё очень плохо, хоть я конечно и проверил всё несколько раз в ворде и тавтологии, так что если что найдёте — пишите в личку, поправлю.

Критика в адрес статьи приветствуется, ибо если нашли косяк в посте, то, скорее всего, нашли косяк в одном из моих проектов.
Алексей @SaveTheRbtz
карма
445,1
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (105)

  • +42
    Плотность полезных ссылок и советов в посте зашкаливает :) спасибо.
    • +23
      Из-за природной скромности автора топика хочу отметить для желающих выразить свою благодарность на следующий его твит:
      Куда бы устроиться только что одипломившемуся студенту, так чтоб колектив хороший, работа интересная и с зарплатой не обижали?

    • 0
      Статья и в самом деле отличная! У меня аж голова заболела от налетевшего объёма информации!!!
  • –1
    блин, ну выбирайте нормальные хостинги для картинок.
    • +2
      Радикал, радикал. Рад ради, кал кал кал.
  • 0
    «уже давно покорится на какой-нить немецкой, свалке»
    вероятно, покоится? :)
  • +4
    Автору респект — пост весьма информативен и полезен.
    В избранном.
  • +2
    Супер! Огромное спасибо! Я как раз пытаюсь разобраться как бы пооптимальнее настроить свой простенький VPS. В скором времени предстоит контролировать большой проект на взрослом хостинге.

    Жаль нельзя отдать все 100 плюсов к карме, которые валяются без дела )8
  • +14
    Ну наконец-то действительно полезный топик среди тонн копипаста и уг. Спасибо, в избранное.

    Насчёт «4.4 Кодировки» думаю заморачиватся не стоит, 1251 прошлый век и сайтов на нём всё меньше и меньше.
    • +3
      Вы правы, ибо наш баг bugs.mysql.com/bug.php?id=46622 является прямым следствием использования cp1251. А память нынче очень дешёвая и ради удобства лучше юзать UTF-8
      Однако если бы у нас было utf8 наша база перестала бы влезать в оперативку ещё полгода назад. Так что пока не накопим денег на «не арендный» сервак, поживём пока на windows-1251
    • +2
      Поддерживаю. Использование UTF-8 позволяет попросту забыть, что такое кодировка. Душевное спокойствие важнее, чем экономия места.
      • 0
        Эээ а я вот слышал что использование утф8 вызывает проблем при вставке BLOB'ов в MySQL-запросе.
        • 0
          Вот этого я не знаю, ибо переехал на постгрес. Впрочем, когда еще пользовался MySQL'ем, тоже все базы держал в УТФ8 и никаких проблем замечено не было. Правда, блобов не было )
        • 0
          А какое дело блобам до кодировок?
          • 0
            А когда пытаешься вставить INSERT'ом BLOB в виде строки, получается непраильная последовательность символов с точки зрения utf8 и ошибка, есоия ничего не путаю.

            // Да и вообще, блобы — муть, т.к. ограничены max_packet_size (несколько мегабайт).
    • +9
      Наконец-то полезный технический пост! Действительно хабр сейчас стал сраным пристанищем копипастеров новостей про крутые блоки питания и нытиков, а появляющиеся новые статьи практически не содержат полезного технического контента.
      Потому что горадо легче кинуть копипаст, чем написать хорошую полезную статью.
      • +1
        Согласен. Читать по кругу «Гаджеты», «Apple», ".NET", уже изрядно надоело. Гораздо больше надоели «параноик-потс» о том, что интернет будет под контролем ZOG^W МВД или Google не удаляет персональные данные.

        Автору, естественно, плюс.
      • +3
        Посмотрите посещемость хабра за последние полгода на какой-нибудь алексе.
        Если учесть, что большинство из людей, имеющих нормальную квалификацию и желание писать, уже давно на хабре, понятно что это за вновь поступивший контингент в подавляющем большинстве. Попса.
        Оно в принципе и ничего бы, но эта свора отбивает желание у нормальных людей писать нормальные статьи. Раньше практически каждый день хотя бы одна сильная статья, но была. Сейчас в неделю две-три…

        Для проекта это возможно и к лучшему (посещаемость, монетизация и т.п.), для желающих читать серьезные статьи — жопа.
        • 0
          ИМХО до июня всё было примерно так-же. В общем, соотношение плохих постов к хорошим осталось таким же, просто объёмы увеличились.
          • 0
            Может у нас критерии/вкусы разные :-)
  • +1
    Да автор проделал большую работу. Большое ему за это спасибо. Очень много полезного. По-больше бы таких статей.
  • –1
    Идеальный пост для хабры! Лучше не придумаешь.
    Большое вам спасибо за статью.
  • –10
    Большое спасибо. Хотя, если говорить о тотальной оптимизации бэкенда, нельзя упускать оптимизацию кода на PHP, это касается и низкоуровневой оптимизации синтаксиса, например конструкция $tmp = $Array[«key»] работает в пару раз быструу аналогичной $tmp = $Array['key'] и на порядок быстрее $tmp = $Array[key] (речь об ассоциативных массивах, типа («key»=> «value»)), и оптимизации алгоритмов, например использования памяти и т.д.
    • 0
      сколько раз уже говорили, что менять for на foreach — это песочница, а не оптимизация
    • +1
      $tmp = $Array['key'] будет быстрее, это так, для справочки.
      • +1
        Спасибо, открыл старые тесты производительности и да, Вы правы. Значит у меня уже крыша едет…
        • 0
          В том то и дело, что они старые.
          Если у вас $tmp = $Array[«key»] не парсится на каждой итерации — разницы между 'key' и «key» никакой.

          P.S.
          Часто вижу ссылки на статью www php spb ru /php/speed.html, которая не изменялась более 6 лет. Это уже давно не так…
        • +3
          У вас крыша едет если вы занимаетесь подобной «оптимизацией» :)
  • 0
    Никак не могу найти работающий пример кэширования fastcgi_cache для гостей (coockies).
  • 0
    Сильно…
  • 0
    > Однако, посмотрев на список deprecated функций в 5.3 можно ужаснутся, благо они пока ещё работают.
    Имхо только dl() из них полезная, да и то на шаред хостингах, где ее обычно запрещают.
    • +1
      в legacy коде deprecated ф-ции часто встречаются. Тот же split(), есть чуть ли не в каждом втором .php файле.
  • +1
    хорошая обзорная статья, пишите еще
  • 0
    Вы софт на FreeBSD ставили из портов или пакетов?
    Если позаморачиваться с флагами сборки софта для портов, то есть шанс ещё немного (а может даже много) выиграть.
    • 0
      Правильные оптимизации могут дать очень хороший выход по производительности. Но там тоже нужно аккуратно — перестаравшись легко потерять стабильность или даже затормозить систему.
    • +1
      Да, всё из портов, что-то из svn/git/etc. С флагами всё немного сложнее: -O3 бывает бъёт приложения, а CPUTYPE может заставить нас пересобирать целиком систему после смены CPU.
      Тут нужно очень индивидуально подходить, тот же XBTT у нас например с -O3 собран, а какойто софт наоборот может даже быстрее с -Os работать.
      Хорошее описалово по оптимизациям gcc есть тут
  • 0
    > Выходом из такой ситуации являлось бы либо хранение глобальных переменных в opcode cacher'e типа APC/eAccelerator.

    Разве в eAccelerator можно хранить свои данные по подобию APC?

    Я с удовольствием заюзал бы APC, если бы не:
    pecl.php.net/bugs/bug.php?id=16787
    pecl.php.net/bugs/bug.php?id=16814
    • +1
      Можно: bart.eaccelerator.net/doc/phpdoc/eAccelerator/_shared_memory_php.html#functioneaccelerator_put
      Хотя я давно его заменил на xcache.
      • 0
        Спасибо за ссылку! А почему заменили?
        • 0
          После очередного обновления php-* возникли проблемы. Кажется, падать начал. Впрочем, это было давно, я точно не помню. С тех пор оставил xcache.
      • 0
        угу, только его собирать надо с этой опцией. из портов/пакетов он без шаредМемори приходит.
    • 0
      Есть еще проблема акселераторов, если проект динамично разрабатываемый, и у него несколько бекенд-серверов, то укатка кода на продакшн проходит неравномерно.
      • 0
        Рестарт php в таком случае разве не помогает? Поидее, кеш в shared memory должен быть сброшен.
  • +2
    Заметки:
    >1.6 Softupdates, gjournal и mount options
    это приводит к падению производительности, куда лучше smartups + скрипт корректно гасящий сервер при выключении питания

    >4.1.2 Переход на InnoDB
    myisam можно починить, если ломается innodb — только восстановление с бекапа

    В целом — очень полный обзор, хотя по оптимизации ядра и включения там нужных плюшек — мало сказано
    • 0
      по поводу innodb вы не правы — его можно восстановить если есть бинарный лог запросов.
      • 0
        Так-же как из бекапа — дроп и восстановление дампа?
        • 0
          в автоматическом режиме dev.mysql.com/doc/refman/5.0/en/innodb-backup.html
          откатывает незавершенные транзакции на момент падения, это даже с отключенными бинарными логами.
          А с бинарными логами подобное можно сделать с контрольной точки, в них лог всех действий в базе.

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

          Механизм схож с тем, что делает Оракл в случае «неожиданной» остановки, что в общем то и не удивительно =)
  • +3
    Хотел бы добавить, что nginx можно использовать для отдачи данных сразу из мемкэша. Для тех страниц которые можно кэшировать целиком, бывает очень полезно.

    Насчет myisam, это нормальный движек, просто в большинстве случаев его используют так как он является дефолтным. А его использовать нужно только если точно знаешь, что не нужны транзакции и не будет insert/select по одной таблице таблице. Для таблиц где только SELECT'ы бегают может быть быстрее InnoDB. Кроме этого не завбывает про замечательный движек ARCHIVE который можно использовать для таблиц с логами.
  • НЛО прилетело и опубликовало эту надпись здесь
  • +8
    Эта заметка должна войти в золотой фонд хабры, я считаю.
  • 0
    спасибо большое за такое количество полезной информации в одном месте )
  • 0
    Написано добротно, но. Меня смущает FreeBSD на серверах DB.
    Файловая система фри ой как желает лутшего. У меня в тестах получалось 20-30% UFS vs. Ext3. А ну и тридинг во фре немного лажает.
    Автор написал что у него бекенд ето PHP — я так понял что PHP как fcgi работает. Или все таки там есть апач? По моих замерах производительность nginx+php на 25-30% хуже чем в apache в позе mpm_worker'а. Ну ето если не компилить php-код каким-то roadsend'ом.
    • +1
      > производительность nginx+php на 25-30% хуже чем в apache в позе mpm_worker'а

      Это вы как считали, что nginx оказался медленнее apache?
      Можно технологию тестирования и результаты? Интересно…
      • 0
        В окружении nginx отдавал всю статику на отдельних доменах. Тест базировался на том, что _только_ php код hi-load проекта обрабативался:

        а) nginx + fastcgi + php
        b) apache(mpm_worker) + zts threading php.
        • 0
          Гм. А php-fpm тестировали? Или каким образом спавнились fcgi?
          И тюнился ли сам PHP?
          • 0
            На тот момент php-fpm был в аццкой альфе и не прошел даже пре тестинг, ну и вообще, IMHO, патчить софт с коробки для большого продакшена — зло.
            PHP тюнился на уровне отключения ненужного, ну и php.ini ондеманд :)
            • 0
              Как раз таки php-fpm был сделан и сейчас используется для большого продакшена. Точно не знаю, но кажется что именно -fpm используется в badoo.com, где и работает создатель этого проекта.
              • 0
                Может я параноик, ну я очень редко, доверяю патчам под рабочий софт, не из портов, если под боком не «работает создатель этого проекта». :)
      • 0
        Технология тестирования — скрипт для форкинга ab на рандом URL'. Интересовала отдача. Результатов сейчас не наведу — остались на пошлой работе :)
    • –1
      Не согласен с «тридинг во фре немного лажает». Шедулер отлаживался и был несколько неадекватен в версиях 5.х, когда делали нормальную поддержку SMP. В 7.х он уже очень даже хорош.

      Про 20-30% UFS vs. Ext3 не верю. Последняя быстрее, но не с таким отрывом.
      Кроме того, автор упомянул ZFS.
      • 0
        Для сравнения попробуйте какой то тридинг-mpm в апаче под нагруженной BSD и увидите о чем я. Вижу тема интересная, попробую в лабе сделать свежий тест.

        Относительно fs то в линуксе шедулер юзал и deadline и noop, правда, на не совсем обычном IBM Blade HS21 + IBM FC Storage DS 4700. Может настолько большая разница из за недоделанности дров для BSD.
  • 0
    SaveTheRbtz, на счёт fstab:
    1. async — это использование оперативки для кэша, а BPU помогает сохранить кэш в RAID устройстве, но не в оперативке.
    2. Вместо noatime рекомендуется всё же relatime, т.к. есть некоторый софт, который ориентируется на atime и может неверно работать с noatime.
    • 0
      1. Был не прав — каюсь.
      2. Во FreeBSD relatime, вроде, нет. Да и массового софта который глючит с noatime кроме mutt я не знаю (если есть яркие примеры серверного софта — пишите). Однако, спасибо, учту, если буду работать с линуксом.
      • 0
        relatime во фре действительно нету
      • 0
        по поводу 2-го пункта.
        правда было дело в Linux, но это, думаю ничего не меняет:
        просесс (который отвечает за кеш) nginx (0.7.61), при включении кеширования на диск, который смонтирован с noatime, начинает съедать весь CPU, что при этом происходит с кешированием хз… отключил сразу когда заметил.

        Воспроизвести ещё раз пока не пробовал, так как это дело лучше держать под контролем…
  • +4
    хм… InnoDB имеет ряд преимуществ и ряд недостатков.
    Лично для меня основное преимущество — блокировки на уровне строки. Тоесть при большом количестве одновременных UPDATE,INSERT не получим столько блокировок таблиц, как на myisam.
    Но InnoDB нельзя срезать бинарно. И это для меня был самый большой минус. Так как таблицы были огромными и гигантские дампы не доставляли радости. Особенно, если при разворачивании дампа закрадывалась ошибка в файле…

    Потому, не стоит рекомендовать всем использовать InnoDB. Надо использовать именно тот storage engine, который подходит твоему проекту, твоей структуре БД и твоим запросам к БД.
  • +1
    Давно ждал такого поста. Многое уже использую. Но рад тому, что нашел для себя ряд новинок.
    Вот, тоже очень интересный материал — www.opennet.ru/base/net/tune_freebsd.txt.html
    • +1
      Да, это как раз и есть предыдущая версия «тюнинга по Сысоеву» Интересно посмотреть, но часть информации уже не актуальна.
  • 0
    Как же интересно кто те трое, что поставили этому топику минус. Черт подери. и как обычно без каких-либо объяснений.
    • 0
      Не обязательно. Когда пользователь жмёт на «—» (посмотреть оценку ни поднимая её, ни опуская), то добавляется по 0,5 и к положительным голосам, и к отрицательным.
      • 0
        в момент голоса — да, но на самом деле это косяк хабра — ничего никуда не прибавляется. если вы перезагрузите страницу, все это 0.5 исчезнут. Можете проверить сами. Сами посудите, если бы прибавлялось — было бы много (~50%) топиков, у которых оценки дробные :)
        • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    как по мне то mysqltuner намного лучше приведенных примеров.
    • 0
      Добавил в топик.
  • 0
    Мне не понравился пункт про кеширование на nginx и на клиенте. Имхо кешировать данные в паммяти должно веб-приложение, та как оно точно знает что и когда изменилось, а что не будет меняться, и уж точно не nginx.

    Кеширование на клиенте — можно конечно и так, тупо «в лоб» прописать всем expires, но только в том случае если вы эти файлы не планируете обновлять.
    • +3
      Кеширование на клиенте — очень хорошая экономия трафика и pps.

      ПС. Обновляем файл — меняем название.
      • 0
        > Обновляем файл — меняем название.

        Руками???? Всюду, где встречается ссылка на него??

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

        • 0
          да ну зачем же руками… формируем все ссылки на статику например вот так domain.com/hash.23442334/main.css, где hash.23442334/ — хеш строка, генерируемая по заранее нам известному паттерну, из урла эту строку убираем рерайтом, так чтоб nginx искал файл domain.com/main.css, при изменении main.css система кеширования должна сообщить генератору документов что теперь пора подставлять новую хеш строку
          • 0
            ну я про примерно такую схему и говорил :)
  • +1
    Вместо встроенного InnoDB в MySQL можно попробовать InnoDB Plugin. Судя по тестам, он дает хорошую производительность по сравнению со встроенным InnoDB.
    • 0
      Это морда оракла как владельца InnoDB смотрящая наружу. Не как владельца Sun, а именно InnoDB. Причем уже не первый год.

      В этом engine уже реализованы гуглопатчи и еще куча фич рихтующих движок. Приблизительно на одном уровне с перконой по характеристикам.
  • 0
    для постгресса посоветовал бы pgAdmin III.
    плюс посоветовал бы отключить автовакуум если большая база и делать аналайз отдельным таблицам.
    и раз в неделю делать фул аналайз с перестройкой индексов
  • 0
    >LVM снапшоты — это тормоз.

    В начале статьи про фрю да про фрю, а потом внезапно LVM. С чего бы это?
    БД на линуксе? Почему?

    >Поскольку самым лучшим инструментом, на мой взгляд, являются клоны в ZFS.

    Как насчет dump/restore из FreeBSD?

    >Делаются мгновенно

    Всмысле, быстрее физической скорости работы накопителей, с/на которые копируются данные?
    Интересно.
    • 0
      >В начале статьи про фрю да про фрю, а потом внезапно LVM. С чего бы это?
      >БД на линуксе? Почему?
      Последний раздел «Приложение. Мелочи.» платформонезависимый.
      Вообще, много кто делает DB на Linux, ибо до 7ки с мултитредингом у FreeBSD было совсем всё плохо.

      >Как насчет dump/restore из FreeBSD?
      тестов я не делал, но судя по тому, что оно юзает снапшоты ufs (dump -L) и соответственно использует copy-on-write, производительность должна падать до уровеня LVM снапшотов.

      >Всмысле, быстрее физической скорости работы накопителей,
      >с/на которые копируются данные?
      ZFS не перезаписывает данные, поэтому снапшот не является «копией» данных, просто те данные которые уже имеются на винчестере не перезаписываются новыми.
      Соответственно создание снапшота, это по сути команда «не перезаписывать вот эту FS, все изменённые блоки писать на свободное место», которая выполняется практически мгновенно.

      • 0
        >Вообще, много кто делает DB на Linux, ибо до 7ки с мултитредингом у FreeBSD было совсем всё плохо.

        Многие делают, но судя по статье у вас никаких проблем с квалификацией администраторов FreeBSD нет. Почему бы не использовать её для серверов БД, тем более для PostgreSQL?

        >ZFS не перезаписывает данные, поэтому снапшот не является «копией» данных, просто те данные которые уже имеются на винчестере не перезаписываются новыми.

        Спасибо за пояснение. Кстати, недавно тут была новость про готовность ZFS в FreeBSD к продакшну, снапшоты там уже реализованы. Вы их имели в виду или снапшоты ZFS на солярисе?
  • 0
    Спасибо за статью! В избранном.
  • 0
    Вы просто монстр…
  • 0
    Если пулер соединений у вас не установлен, то на каждое соединение с базой у вас запускается отдельный процесс

    Некорректная формулировка. С пулером или без, число процессов равно числу клиентов. Пулер же просто держит пул открытых соединений, убирая оверхед создания нового процесса при подключении клиента (и прибивания процесса при отключении), так что, например, после кратковременной серьезной нагрузки у вас останется висеть довольно долго куча ничего не делающих процессов.
    В общем, да, пулер безусловно необходим.
    • 0
      >С пулером или без, число процессов равно числу клиентов.
      вот тут не согласен, мне всегда казалось, что в случае pgBouncer количество процессов максимум может равнятся default_pool_size + reserve_pool_size, если их больше, то они просто ставятся в очередь.
  • +1
    Класс. Хорошая статья — это когда тонны пунктуационных ошибок даже не замечаешь. Особое спасибо за ссылки.
  • +1
    Очень профессионально, в мемориз однозначно.
  • +2
    Полезная статья — зачет! :-) Пригодится как краткий справочник и набор связных ссылок.
    На мой взгляд применительно к сетевушкам не стоит всем сразу поллинг рекомендовать — пусть сначала хотя бы загрузку по прерываниям посмотрят. А то уже который раз везде вижу, что народ считает поллинг каким-то универсальным способом решения всех проблем. ;-) А на тех же em он вообще сильно вреден. И nfe, кстати, очень неплохие сетевушки — нагрузку держат адекватно, производительность хорошая и с прерываниями как раз не шалят… Еще можно предостеречь от msk — их сейчас много (D-Link DGE-560T), стоят дешево и есть большой соблазн купить и поставить. И ведь даже работать будут под небольшой нагрузкой… А потом начнут тупо выключаться. Уже почти год мой bug висит, подтверждения на него от других людей есть, а хоть бы хны… И еще напишите, что далеко не во всех em есть все ништяки. pci-e Интеловские карточки действительно большей частью стоят своих денег. :-)
    Насчет ZFS — нужно было хотя бы упомянуть в разделе про файловые системы. На amd64 оно production ready уже очень давно и даже ядро тюнить не надо (у меня несколькотерабайтный файловый сервер несколько лет работает нормально). В восьмерке довели до того, что на i386 работает из коробки, но я бы и на 7.2 amd64 сейчас собирал не боясь… Слишком уж там raidz вкусный. :-)
    И про InnoDB в комментах уже говорили — если не нужны транзакции и атомарность (а они нужны далеко не везде, особенно если сам сидит и проектируешь базу), то MyISAM вполне себе в деле. :-) Ну и что, что табличка может побиться? Се ля ви, так сказать (тем более, это не такое уж частое являение). Зато если она КОНКРЕТНО побилась, то пусть и не быстро, зато восстановится она без особого напряга безо всяких бэкапов. Кроме того, не забывайте о скорости и памяти — таки на VDS, особенно на младших тарифах, это вполне себе играет определенную роль… Короче, InnoDB не есть панацея для всех случаев. Я бы лучше порекомендовал начинать проект как раз на MyISAM, а когда проект вырастет, уйдет с VDS на свой сервер да и о репликации базы начнете думать — тогда да, уже InnoDB. А ежели в проекте табличка еще меньше гига, а ее из-за MyISAM уже блокировки замучали, то, извините, это не в MyISAM проблемы, а в том, кто базу и ее приложения проектировал. :-)
  • 0
    Спасибо за статью!
  • 0
    По поводу багов в MySQL 5.1, не в обиду самому мускулю, сам им пользуюсь все время. Просто так сложилось, что сам вчера переходил с 4ки на 5.1. Так вот серак 5.1 валится если в названиях полей использовать несколько тире. Например «bred-------»
    Поля подобного рода у меня использовались для визуальной группировки полей в таблице во время разработки проекта. нигде они ессесно не используются в проекте, поэтому проект работает, а мускуль падает при обычной процедуре дампа. Понадобилось 30 минут что бы выкупить :)
    • 0
      ну так в мануал заглядывать перед такими переездами стоит
      dev.mysql.com/doc/refman/5.1/en/ansi-diff-comments.html
      • 0
        Вы действительно думаете, что однострочный комент появился только в 5.1? И вы действительно думаете, что это оправдание тому, что сервер тупо падает, а не ругается?
        Хотя спорить с вами по всей видимости нет смысла ибо вы текст по ссылки не читали:
        • 0
          Using our implementation requires a space following the “--” in order for it to be recognized as a start-comment sequence in MySQL Server 3.23.3 and newer. Therefore, credit--1 is safe to use. Another safe feature is that the mysql command-line client ignores lines that start with “--”.
  • 0
    Немного не по теме — а как насчет CentOS? Одни админы рекомендутю FreeBSD, другие CentOS. Непонятно. :)
    • 0
      Забыли ещё тех, кто рекомендуют Debian =)

      Вообще есть 2 критерия выбора ОС:
      1) Выбирать ту, которая лучше подходит под конкретную задачу
      2) Выбирать ту, которую лучше знаешь

      Обычно выбирают второе, что не всегда правильно.
      • 0
        да, каждой задаче своё.
  • 0
    Спасибо, много интерестных вещей.
  • 0
    Великолепный материал, то что нужно, в закладки, спасибо .)
  • +1
    «TCP Segent Offloading» — segMent
    • 0
      Да, я давно хотел попроавить опечатки в recEive и segMentation но у меня теперь этот текст больше не редактируется.
      Хабр пишет «Some error… We know...» может сильно client_max_body_size уменьшили
  • 0
    Припозднился я конечно, но не отдать дань уважения не смог. Для обладателей VDS с амбициями, этот пост — боевой листок.
    Спасибо!

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.