Python-сообщество

Есть работающий сайт, написанный на Python (Django), и БД - MySQL.
Так как разработчики не сильно потрудились над написанием оптимизированного кода, сайт получился очень тяжелым. И при посещаемости в десяток тысяч в день, в пиковое время сервер не справляется с нагрузкой и выкидывает тех кого не успел обслужить.
Вот система физического сервера:
1. 2 ядра по 1,8GHz
2. ОЗУ 2Гб

Вот на чем сейчас сервер развернут:
mysql + nginx + fastcgi

Так вот вопрос: хотелось бы услышать мнение бывалых, опытных, или просто знающих, на чем можно еще развернуть данный сайт, дабы было максимально быстро, ресурсо ёмко? Или же данная связка является самой быстрой? Может кто делал сравнение быстродействия.
А также возможно кто-то в курсе как оптимизировать работу сервера так чтобы гиганское количество запросов в БД не ложило сервер, может какая-то настройка?
Спасибо.

Связка тут не причем (эта нормальная)
Тут нужно анализировать, искать узкие места, кешировать на разных уровнях и т.п.
Какая нагрузка в пиковое время?
fastcgi - сколько потоков, процессов?

ЗЫ: Чаще всего тормоза в БД.

Отредактировано (Июль 12, 2011 19:25:41)

В джанге куча встроенных инструментов кеширования, мерьте и кешируйте, мерьте и кешируйте

o7412369815963
Какая нагрузка в пиковое время?
fastcgi - сколько потоков, процессов?

ЗЫ: Чаще всего тормоза в БД.

В пик более 100 пользователей.
worker_processes (если вы об этом) то 1.

Да тормоза из-за БД, сильно много и сложные SQL запросы, собственно с этим сервер и не справляется, по наблюдению за сервером почти всегда MySQL забирает больше 60% процессора, память тоже кушает, хотя процесс python все же больше памяти съедает.

PooH
В джанге куча встроенных инструментов кеширования, мерьте и кешируйте, мерьте и кешируйте

Ок, приму во внимание. Никогда подобным не занимался, не знал, теперь предстоит.

KarDer_Groom
1. 2 ядра по 1,8GHz
worker_processes (если вы об этом) то 1.

я бы сделал процесса 4 (можно 2) - что-б грузить все ядра.
потоков штук 10 на процесс - пока одни потоки будут висеть в ожидании ответа от БД другие будут работать.

Надеюсь статика отдается nginx-ом?

ну и конечно всякое кеширование…

o7412369815963

KarDer_Groom
1. 2 ядра по 1,8GHz
worker_processes (если вы об этом) то 1.

я бы сделал процесса 4 (можно 2) - что-б грузить все ядра.
потоков штук 10 на процесс - пока одни потоки будут висеть в ожидании ответа от БД другие будут работать.

Надеюсь статика отдается nginx-ом?

ну и конечно всякое кеширование…

Пока что поставил 2 процесса.
потоков у меня - worker_connections 1024;

Статика конечно отдаётся Nginx'ом

Смотрю состояние рабочих процессов ps ax -o %cpu,vsz,wchan,command | grep “nginx\|PID”
В колонке WCHAN везде прочерки, так понимаю что в ожидании нет процессов, подожду немного, потом 4 процесса попробую.
(По мотивам этой статьи http://www.httpd.kiev.ua/tips/nginx/number-of-worker-processes/)

KarDer_Groom
подожду немного, потом 4 процесса попробую.

сейчас разница будет незаметной т.к. это не основной тормоз.

Отредактировано (Июль 13, 2011 19:53:02)

Если используются MyISAM таблицы, то запустите mysqltuner (скрипт ничего не меняет, просто анализирует состояние mysql) и выложите то, что он покажет (наверное лучше прикрепить файлом, там достаточно объемный вывод). Конфиг mysql тоже покажите. Чуда точно не получится, но если у вас дефолтные настройки, то можно заставить сервер работать чуть бодрее.

Если затык в базе данных, переходи на постгри и переписывай сложные моменты на pl/sql а то и на cи. Это очень эффективный метод.
Если захочешь выиграть в мелочах, то избавляйся от fcgi в пользу uwsgi. Выиграешь не много, но просто и приятно.

ZZZ
Если захочешь выиграть в мелочах, то избавляйся от fcgi в пользу uwsgi. Выиграешь не много, но просто и приятно.

Да, и зубную пасту поменяйте на Colgate. Толку никакого, но зато хоть какой-то совет.