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

[Дмитрий Леоненко]

Все логично и супер, но работы на 2 недели. Быстрее Linux поставить :))))

2007/1/13, Yuri Kushinov <yuri.kushinov at gmail.com>:
>
> > Ну что могу сказать, крутится 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20070113/563112d4/attachment.html>