Скажу честно, управление srx'ом мне понравилось больше чем cisco. Более грамотно организован дебаг. Более грамотно вывод конфигов. Да даже просто вывод нужного модуля вместо вывода всего конфига — очень полезно. У кошек такое тоже есть но только по некоторым модулям конфига. Например sh run int fa 0/1.1. Но вот посмотреть блок про бгп уже нельзя так.
По поводу качества говорить конечно тоже не решусь. Но думаю на таком количестве оборудования стоило сделать централизованное распространение конфигов по, например, tftp. И не было бы проблем со сдохшим оборудованием. Переписываешь новый мак на сервере и просишь передернуть железяку или установить новую.
кто-то на хабре предлагал virttool
очень приятная оснастка на django, не требует софта на нодах. Но пока плохо понимает KVM.
За то все лаконично и приятно. И из используемых технологий Django + libvirtd for python. Никаких больше зависимостей не требуется.
Думал об этом. Не понравилось что ноды придется разворачивать заново. Так как:
1. рекомендуют свой ISO для разворачивания нод
2. если не ошибаюсь репозитории подготовлены только по deb
Спасибо за статью. Сам использую чистый CentOS + KVM и очень доволен. Пока серверов не много, вполне устраивает virt-manager. Хотя уже начинаем поиски некоевого централизованного управления, с основным требованием — что бы это дело управлялось исключительно через libvirtd. Для универсальности так сказать.
Может кто что подскажет?
Тут вы правы! dev.mysql.com/doc/refman/5.1/en/internal-temporary-tables.html
In some cases, the server creates internal temporary tables while processing queries. Such a table can be held in memory and processed by the MEMORY storage engine, or stored on disk and processed by the MyISAM storage engine. The server may create a temporary table initially as an in-memory table, then convert it to an on-disk table if it becomes too large. Users have no direct control over when the server creates an internal temporary table or which storage engine the server uses to manage it.
Но на лично у меня кладется достаточно большой процент. Больше 20%. Я так понимаю это частое явление и у меня не получилось сильно на него влиять. Так что хоть немного их оптимизировать желательно.
Вот придирчивые все. Специально для Вас! dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_tmp_table_size
The maximum size of internal in-memory temporary tables. (The actual limit is determined as the minimum of tmp_table_size and max_heap_table_size.) If an in-memory temporary table exceeds the limit, MySQL automatically converts it to an on-disk MyISAM table. Increase the value of tmp_table_size (and max_heap_table_size if necessary) if you do many advanced GROUP BY queries and you have lots of memory. This variable does not apply to user-created MEMORY tables.
You can compare the number of internal on-disk temporary tables created to the total number of internal temporary tables created by comparing the values of the Created_tmp_disk_tables and Created_tmp_tables variables.
1. Полностью согласен и предлагал. Пока отказались.
2. По поводу memcached'a — тоже согласен, хотя и не во всем. MySQL достаточно эффективно кеширует похожие запросы на чтение, если они верны. А если они не верны то не спасет и memcached
Я уже отвечал на этот вопрос господину выше. kDas. О том что сами разработчики не знают как влияет тот или иной параметр. Потому как они могут ожидать один результат а на практике выходит другой.
Согласен с Вами что аналогия с реестром есть. Процитированные Вами строки призывали гуру подсказать что стоит менять. Я не претендую на 100% знание mysql, но поскольку результат есть, думаю и статья имеет место быть!
Как уже говорил, бд на сегодняшний день уже на отдельном сервере. Так же я планирую сделать много виртуалок с апачем, которые будет проксировать nginx. Так что насчет сокетов, видимо не получится. А на счет портов — похоже столкнусь на nginx'e когда он будет единым и центральным
Там было еще много интересных фишек, но программеры на самом деле отличные и исправляли все за считанные минуты. В общем и целом мне с ними работать понравилось и надеюсь на дальнейшее сотрудничество.
nginx работает от своего пользователя и у этого пользователя нет shell, но проверял применение значений я именно путем включения shella для этого пользователя и запуском ulimit из под него. Я проверю, спасибо!
Тут вы 100% правы. Не рискнул писать про эти переменные так как никак не могу у себя в голове уложить как они работают. Вроде как выставил почти под всю ОЗУ но не уверен что это верно. Сможете подсказать читателям как их правильно считать? Я имею в виду shmmax и shmmal
Спасибо. Если читали комменты, то уже переехали на Percona. Догадок много потому что mysql такой. Даже на www.mysqlperformanceblog.com/ неоднократно говорят о неоднозначности параметров конфига и о документации. Я лишь обратил внимание на то куда стоит смотреть.
Настчет рельсов — тут как вариант еще и торнадо и джанго. Но они все php любят почему-то.
Пинать не буду, это было условием совместной работы — то что они в данном приложении остаются на PHP. Чую уже переписывали просто и больше на это бюджета не выделят.
Что скажете про php-frm?
На memcache пытался их пересадить. Упираются пока. Но думаю все впереди. Когда следующие затыки начнутся.
Если серьезно, я понимаю что все это тысячу раз описано. Цель была описать основные моменты и направления развития для того кто сталкивается первый раз. Когда я столкнулся, мне бы данная инфа или хотя бы список ссылок очень пригодились. Материал поверхностный и многие детали оставлены без внимания. А многие кучу раз уже описывались. Еще раз. Цель — собрать во едино все основные проблемы и беды подобных проектов.
Я надеялся что статься будет хорошей, когда ее дополнят критикой. Потому как все что тут описано, хоть и перечитано неоднократно мной лично, не факт что является истиной. Может у кого-то есть другие мнения. Но все равно спасибо за лестные отзывы. По мере изменения буду добавлять. Могу так же описать процесс переноса на Percona если кому интересно. Хотя подводный камень там был лишь один — правильные права на lvm том. Ну и плюс некоторые изменения в синтаксисе конфигурационного файла.
percona 100% совместима с mysql. Это ее форк. Советовать или не советовать пока не буду. Поскольку еще не сталкивался с ней с проблемами. По скорости работы дала возможно лучшие результаты, а возможно все дело в том что я запихнул базу в raw lvm раздел, а LVM как говорил ранее на 10 рейд повесил.
По поводу качества говорить конечно тоже не решусь. Но думаю на таком количестве оборудования стоило сделать централизованное распространение конфигов по, например, tftp. И не было бы проблем со сдохшим оборудованием. Переписываешь новый мак на сервере и просишь передернуть железяку или установить новую.
очень приятная оснастка на django, не требует софта на нодах. Но пока плохо понимает KVM.
За то все лаконично и приятно. И из используемых технологий Django + libvirtd for python. Никаких больше зависимостей не требуется.
1. рекомендуют свой ISO для разворачивания нод
2. если не ошибаюсь репозитории подготовлены только по deb
Может кто что подскажет?
dev.mysql.com/doc/refman/5.1/en/internal-temporary-tables.html
In some cases, the server creates internal temporary tables while processing queries. Such a table can be held in memory and processed by the MEMORY storage engine, or stored on disk and processed by the MyISAM storage engine. The server may create a temporary table initially as an in-memory table, then convert it to an on-disk table if it becomes too large. Users have no direct control over when the server creates an internal temporary table or which storage engine the server uses to manage it.
Но на лично у меня кладется достаточно большой процент. Больше 20%. Я так понимаю это частое явление и у меня не получилось сильно на него влиять. Так что хоть немного их оптимизировать желательно.
dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_tmp_table_size
The maximum size of internal in-memory temporary tables. (The actual limit is determined as the minimum of tmp_table_size and max_heap_table_size.) If an in-memory temporary table exceeds the limit, MySQL automatically converts it to an on-disk MyISAM table. Increase the value of tmp_table_size (and max_heap_table_size if necessary) if you do many advanced GROUP BY queries and you have lots of memory. This variable does not apply to user-created MEMORY tables.
You can compare the number of internal on-disk temporary tables created to the total number of internal temporary tables created by comparing the values of the Created_tmp_disk_tables and Created_tmp_tables variables.
2. По поводу memcached'a — тоже согласен, хотя и не во всем. MySQL достаточно эффективно кеширует похожие запросы на чтение, если они верны. А если они не верны то не спасет и memcached
Согласен с Вами что аналогия с реестром есть. Процитированные Вами строки призывали гуру подсказать что стоит менять. Я не претендую на 100% знание mysql, но поскольку результат есть, думаю и статья имеет место быть!
Настчет рельсов — тут как вариант еще и торнадо и джанго. Но они все php любят почему-то.
Пинать не буду, это было условием совместной работы — то что они в данном приложении остаются на PHP. Чую уже переписывали просто и больше на это бюджета не выделят.
Что скажете про php-frm?
На memcache пытался их пересадить. Упираются пока. Но думаю все впереди. Когда следующие затыки начнутся.
Если серьезно, я понимаю что все это тысячу раз описано. Цель была описать основные моменты и направления развития для того кто сталкивается первый раз. Когда я столкнулся, мне бы данная инфа или хотя бы список ссылок очень пригодились. Материал поверхностный и многие детали оставлены без внимания. А многие кучу раз уже описывались. Еще раз. Цель — собрать во едино все основные проблемы и беды подобных проектов.