Re[2]: Нагрузка на FreeBSD

[Yuri Kushinov]

> Ну что могу сказать, крутится vBulletin и форум очень посещаемый (в
> пиках 700 уникальных в течении 15 мин.), на линкусе, где он до этого
> стоял (2xXeon 5130, 4Gb, RAID5) нагрузка не превышала в пиках 25%
> процессора. Тут, на новом сервере FreeBSD 6.2 (Pentium D 940, 2
> ядра, 2GB) и такие жуткие перегрузки. 
> Я не столь опытен во FreeBSD, что бы знать все подводные камни, но
> зная, что в рассылке есть люди, сильные в этой ОС, решил просить
> помощи. FreeBSD на новом сервере не по своей воле выбрал, потому
> теперь только бороться осталось... 
> Не пойму, как на линкусе php и БД не давали такой страшной нагрузки, а тут дают?


 1. У вас стало в два раза меньше RAM.
 2. У линукса подсистема ввода/вывода имеет более хорошую логику
    кэширования часто запрашиваемой информации.  Так что у вас фактически была
    двойная буфферизация данных БД - одна на ключах/буфферах MySQL, другая на уровне OS.
    Это так же помогало при записях/обновлениях БД.
 3. Gentoo обычно всегда означает nptl, который никак не сравнится с pthreads.
 4. RAID5 - а на новой машине?

 Мощность процессора возможно реализовать на 90-100% /только/ при
 условии кода близкого к идеальному и/или быстрого RAIDа и/или оптимальных
 запросов к БД.

 У вас же проблема налицо - MySQL, являсь самым последним звеном в
 "логической" цепочке обработка запросов, банально и безбожно
 тормозит.
 
 nginx
    apache
       php
          mysql
             i/o

 Посмотрите на mytop - запросов много? как долго они выполняются? Для
 самых медленных из них проведите EXPLAIN и посмотрите хорошо ли они
 индексированы. Если да - и запрос всё равно выполняется долго, то вам
 вероятно надо увеличить key_buffer_size или innodb_buffer_pool_size,
 в зависимости от того что вы используете.
 Если у вас MyISAM, то почаще оптимизируйте таблицы.

 Посмотрите на загрузку дисков - если они постоянно на отметке 100% -
 то вот ваш bottleneck - постарайтесь каким-то образом эту нагрузку
 снизить.. Из-за него страдает не только отдача статики, но и очень
 сильно MySQL.
 Уберите noatime с параметров mountирования партиции, настройте
 буффера в nginx, руководствуясь error_log *log_path* debug; чтобы он не
 писал временные файлы на диск если размер/количество буфферов не
 достаточен(..чно).
 В крайнем случае поразмыслите над запихиванием всего кода фрума на
 ramdisk.

 Понаблюдайте за статусами ngix (stub_status on) и Апачевским
 /server-status на предмет открытых соединений и их количества,
 сделайте выводы.
 Протрассируйте все этапы выполнения запроса на
 какую-либо страницу и найдите где этот запрос стопорится на самое
 длительное время.

 Полазте по системным логам (ошибки нехватки
 памяти/буфуров/сокетов/слотов, неверных прав на файлы), почитайте dmesg,
 потыкайте в sysctl - может вы просто попали в какой-то глупый лимит ресурсов.

 Подходите к проблеме креативно. Не описывать же сейчас
 пол-интернета статей по оптимизации серверов, причём сразу всех :)

-- 
Best regards,
 Yuri Kushinov                            mailto:yuri.kushinov at gmail.com