percona 100% совместима с mysql. Это ее форк. Советовать или не советовать пока не буду. Поскольку еще не сталкивался с ней с проблемами. По скорости работы дала возможно лучшие результаты, а возможно все дело в том что я запихнул базу в raw lvm раздел, а LVM как говорил ранее на 10 рейд повесил.
С ней он справлялся и до оптимизации. Заказчик делает некую рассылку и пользователей на сайт приходит до 1500 за единицу времени. Вот тогда сервер начинал загибаться за 5-10 минут.
Сделали совсем по другому. Сейчас там выделенный сервер под бд. 16Гб ОЗУ вместо 64, но 4x300Гб SAS диски в рейд 10, аппаратном. А бд сейчас Percona. Вот это реально дало производительности столько что сервер не нагружается вообще.
Не хотел акцентировать внимание на другие сервера, так как в принципе все делается на одном.
Может я не так выразился, но nginx'а 2. Один который поднимал я перед апачем. Другой висит на соседнем сервере и обслуживает часть статики. Так сделали до меня. А запись домена вела на апач и позже на мой nginx, а картинки в html коде запрашивались по ip со второго. Вроде бы я это уже описывал хотя и менее подробно.
потому что там бардак, за исправление которого никто не платит. Я описывал изменение одного из 3 серверов. Вся статика как казалось заказчику находится на другом сервере с nginx'ом. А запросы шли напрямую по ip к нему. Но как оказалось не вся.
я бы и от мускуля в пользу redis'a или другого nosql решения отказался. Но на текущем этапе я не смог даже добиться что бы программисты перенесли данные сессий в memcache или хоть куда с диска.
согласен полностью. Проект не мой, ко мне обратились быстро найти и исправить основную проблему. И надо было что-то сделать быстро. Плюс заказчик отказался на первом этапе от переделки.
Там еще много косяков. 2 nginx'а тоже лишнее.
В общем по мере развития и запросов буду отписываться как и что делал, если интересно
Насколько я понимаю, на сложных запросах mysql строит временные таблицы и они то как раз MyISAM. Действительно не нашел подтверждения что они коррелируются, но как я уже сказал, за основу взять файл из тарбола mysql, оптимизированный под innodb
Если честно, на данный момент мне больше всего понравилось работать с vyatta. Это конечно опять роутер в большей степени. Хотя там вроде snort даже включен.
По поводу cisco cli против junos — по мне так очень похоже, если понимать концепцию устройства.
Есть один нюанс который я так и не понял как в JunOS реализовать. В cisco я когда админю удаленную железяку, я могу запланировать перезагрузку, если вдруг ошибусь с access list'ом на ssh снаружи.
Вот с этой концепцией я пока не знаю как мириться. Но думаю надо просто почитать Juniper tips&triks
не верю я в 650Mbps, да и интерфейсы FE таки.
да, логин ротом дает шелл. В руководстве по этому и написано создать пользователя, который будет админ но без рут шелла
Может я не так выразился, но nginx'а 2. Один который поднимал я перед апачем. Другой висит на соседнем сервере и обслуживает часть статики. Так сделали до меня. А запись домена вела на апач и позже на мой nginx, а картинки в html коде запрашивались по ip со второго. Вроде бы я это уже описывал хотя и менее подробно.
Там еще много косяков. 2 nginx'а тоже лишнее.
В общем по мере развития и запросов буду отписываться как и что делал, если интересно
По поводу cisco cli против junos — по мне так очень похоже, если понимать концепцию устройства.
Есть один нюанс который я так и не понял как в JunOS реализовать. В cisco я когда админю удаленную железяку, я могу запланировать перезагрузку, если вдруг ошибусь с access list'ом на ssh снаружи.
Вот с этой концепцией я пока не знаю как мириться. Но думаю надо просто почитать Juniper tips&triks
да, логин ротом дает шелл. В руководстве по этому и написано создать пользователя, который будет админ но без рут шелла