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

Ну так покажите как ее готовить:evil:, тут вообще-то помощи просят.
на фрилансер.ру очередь выстроилась желающих решить проблему, я четверым дал возможность попробовать...
Видно там все криворукие  тусуются:)

"nginx позволяет экономить ресурсы сервера" - и что?   это означает что при включении nginx тест производительности  должен сильно прибавить?
Читайте что я пишу выше: 95% ресурсов сервера при выполнении теста свободны.

Ссылку дал на закрытый форум разработчиков, обладатели лицензии туда не могут попасть

Николай, мы с этого начинали кеш хранился изначально в файлах, потом переключил на АРС, никакого влияния не оказало

Извиняюсь, пока тема висела, не прочел прошлое сообщение ...

Oleg_,  Смотря на картинку Вашего скрина произвjдительности от 18.02.2012 01:17:01 складывается впечатление, что на сервере в момент теста выполнялось что то еще. Потому что у меня на сопоставимом сервере (Intel Core i7 950@3.07GHz / 8GB /без hardware RAID) под "лёгкой" нагрузкой показатели CPU, файловой системы и БД примерно в 2 раза больше ваших.


Про 5% загруженность. Тест на "отклик" и на "процессор" - однопоточные. А процент считается от всего процессора. У вас похоже 8-поточный процессор, и загрузка более 12.5% не должна была подниматься. А видимо потому, что тест касался не только процессора - видимо потому у вас 5% и получилось.

У вас на сервере 8 потоков по 3.2GHz - вычислительная часть многократно мощнее. Памяти больше - тоже хорошо. Единственно, виртуалка может соревноваться с выделенным сервером тогда, когда на ней дисковая система оптимальнее вашей, да и то, только тогда, когда сервер с VPS не нагружен.
А для "реального" сравнения - запустите и там и там тест с закладки "Маштабируемость". На минуту, с 2 до 12 соединений, с шагом 2.

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

Алексей Власов,  а htop по прежнему показывает MySQL самым грузящим просессом?

Еще одно замечание -

Напомню в каталоге порядка 300 тыс позиций, так вот есть страничка сайта, на которой находятся 2 компонента catalog.top
В процессе генерации страницы загрузка сервера 100%

Время создания страницы: 8.9442 сек.
Всего SQL запросов: 84
Время исполнения запросов: 8.1781 сек.

Oleg_,  у вас пожалуй стоит определить, где узкое место - файловая система или сам диск. В linux есть команда
hdparm -tT /dev/sdX
думаю, во FreeBSD есть аналог. При этом в тесте "Timing buffered disk reads" не вмешивается кэш ОС, в отличии от dd. Современные сервера пустыми, на недорогих дисках, дают от 100 MB/sec "чтения с диска".
Если же сервер покажет хорошую скорость диска, то видимо дело в настройке файл-системы. Из простого - проверить установленный noatime (Битрикс его любит).

RAID-0 - на сервере это жестко, не стоит )
А то что у виртуалки "быстрый" диск - это скорее всего хороший кеш-сервера.

Что касается "результата" теста производительности - то можно пожертвовать "Веб-Антивирус", "Проактивный фильтр" - это улучшит конечный показатель.

Также надо перепроверить все "прицепленные" акселераторы. Поддержка например правду говорит, что APC лучше чем eAccelerator.

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

Алексей Власов,   92 - вполне нормальные показатели. Так как у вас на странице бОльшее время занимают запросы то надо определить, по какой причине, и тогда станет ясно, возможно ли оптимизировать работу настройкой сервера или же надо что то делать в коде сайта.

UP.
Найдите самые тяжелые запросы, вносящие максимальный вклад в "Время исполнения запросов", посмотрите их EXPLAIN.
В EXPLAIN внимание обратите на запросы, где много ROWS, и где используется сортировка с использованием временных файлов.

чета совсем плохо, и при этом 92 показывает:o
зацените загрузку диска во время теста у меня....
и при этом 14 показывает:(
ниче не понимаю в этой жизни:oops:

Алексей Власов,  - теперь надо смотреть сам запрос, какие части таблицы с псевдонимом BE участвуют в "where" и дальше. У вас проблема в том, что
а) Mysql затрачивает кучу дисковых операций на выборку 261006 строк данных
б) эти данные скорее всего настолько велики по объему, что при выборке создается временная таблица на диске.
Т.е. сначала mysql читает с диска данные, потом туда опять их пишет, потом только отдаёт вам.


Варианты дальнейших действий:
1. возможно переписать запрос, чтобы подвести как можно ближе под индексы, или индексы подвести под запрос - это может уменьшить цифру 261006 (самый "продвинутый" метод, если только возможен)

2. переписать запрос так, чтобы выбирались только нужные поля - тогда размер 1строки результата будет * 261006 - будет меньше, и может получиться обойтись без временных таблиц на диске.

3. примерно посчитать длину строки результата, умножить на 261006 - получиться примерно размер временной таблицы - разрешить создавать такие таблицы в памяти MySQL это параметры
tmp_table_size = xxxM
max_heap_table_size = xxxM
НО возможно высчитанный xxxM будет неприлично велик для системы, всё зависит от размера памяти сервера
update
Судя по всему BE - это b_iblock_element. У меня длина строки таблицы - 3523 байта, при перемножении получается около 900МБ - примерно такой объем данных проворачивает ваш сервер при запросе. Потому вариант с tmp_table_size  и max_heap_table_size получается неудачным.
Если у вас на сервере оч.много памяти и таблица b_iblock_element в innodb, можно еще выставить большой
innodb_buffer_pool_size
может быть 2GB, может бльше, более точно подобрать можно по анализу отношения Innodb_buffer_pool_pages_free к Innodb_buffer_pool_pages_total - чем оно больше, тем дольше в кеше будет висеть b_iblock_element


4. использовать цифру из п.п.3, умножить в несколько раз и сделать такого размера диск в памяти, через tmpfs и указать её как папку для временных файлов MySQL

5. самый простой метод, если актуальность данных выборки не критично - делать выборку раз в XXX секунд по крону, сохранять её результат и показывать "из кеша", или же настроить кеш надолгое хранение выборки

Oleg_,  у меня отключение проактивного фильтра и  *  улучшило результат в 2 раза, с 14 до 28,  APC и eAccelerator вместе - не дружат, а влияние memcached у меня на показатель оказалось невелико. Но вероятнее всего в реальном приложении memcached поможет больше.

Алексей Власов, - если силой забить не получается - надо что то делать с самим запросом. Присылайте, посмотрим )


А какие значения у вас
Innodb_buffer_pool_pages_free
Innodb_buffer_pool_pages_flushed
Innodb_buffer_pool_pages_total

после отработки этого скрипта?

Алексей Власов,  неприятно, что pool не дал прироста. Тогда видимо можно спокойно уменьшить память для пула вдвое и для tmp_table до "разумных" цифр.

А вариант с tmpfs пробовали? Он как раз может обойти ограничение
Вообщем попробовать чтобы и память свободная (Innodb_buffer_pool_pages_free ) была, и чтобы tmp от MySQL смотрел на "диск" в памяти.

Ну и запросик (вместе с cre ate table всех используемых страниц если они нестандартные + примерное число записей в них) глянуть можно?

ДЛя фс прописал noatime

Вопросы на завтра среднее время отклика очень высокое + детально настрою nginx
Посмотрим что получится


Александру огромное спасибо за помощь !