Но я таки полагаю, судя по графикам, что основной проблемой была запись tmp таблиц в тот же раздел диска куда и вся нагрузка сваливается... По крайней мере понимаю откуда могли браться i/o wa, а как следствие и тупо торможение обычных процессов под которые база вполне оптимизирована...... Есть здравый смысл в этом?
// Спад на графиках после перехода tmp с "/" в shm.
[--] Up for: 46m 23s (1M q [393.487 qps], 12K conn, TX: 12B, RX: 90M)
[!!] Query cache prunes per day: 6026764
Вот это действительно интересно..... 6 mln за 46 минут.... :(
При предложенных вами настройках, увеличивать еще кеш для запросов?
| query_cache_limit | 67108864 |
| query_cache_size | 536870912 |
Это я прекрасно понимаю.
Вы знаете, я например не могу себе представить ситуацию в которой 100% запросов будут кешированы, это просто не реально !!!! По этому отличная от нуля query prunes это нормально !!!! или я не прав? Как и в какой кеш можно положить все запросы которые прошли через SQL сервер например за 10 дней, да у вас и 10000 GB памяти не хватит я полагаю :) Это что бы пруны = 0 :) Т.е все запросы прошедшие сквозь SQL были закешированы и ни один из них не был выкинут из кеша .......
Возможно конечно значение в 18 мильенов это перебор, так это другой разговор, получается, что кеш очень часто очищается.... и ваши праметры обретают какой-то осознанный смысл, попробую увеличить размер кеша.
Выпады не выпады, понимаете ли, я на форуме как и вы не первый день, вижу многое и разное, по этому если вы не разобрались что я хостер и предлагаете мне нанимать администратора, это я тоже могу считать как выпад с вашей стороны, но я молчу :D Ровно как и советы из серии "мне нравятся эти цифры", я привык к конструктивному диалогу на повышенных тонах, именно в такой атмосфере и принимаются наиболее верные решения, нужны споры, обсуждения, дебаты, как хотите это называйте. Если вы говорите, надо 32 мегабайта, будьте готовы пояснить почему, в противном случае вы с первого сообщения флудите в теме.
Общаться или нет со мной - ваше личное дело. Мы свободные люди. Принуждать вас общаться с собой )))) не буду :))) ---------- Добавлено 06.02.2013 в 05:01 ----------
Это ваше "будущее" прямо вообще максимализм какой-то :) Что там в будущем интересного то ? Старость? :) А специально из будушего в ваше прошлое, я написал в первом посте, что предоставлю любую информацию которая вам будет требоваться для анализа за исключением рутового пароля :D :D :D Если читать внимательно настоящее , то можно понять , что именно оно и формирует будущее. ---------- Добавлено 06.02.2013 в 05:05 ---------- И вот опять же "Ставят max connections как попало"..... а вы предлагаете не обращать внимание на то, что при максимальной нагрузке на SQL будет скушано 200% доступной памяти? (Не ясно что хуже.... :D ) Фигня получается, вы не в будущее смотрите а вообще не ясно куда... Допустим, что у меня действительно 10 коннектов это потолок, и при ваших настройках у меня 600 мегабайт уйдет на их обслуживание, разве вы считаете верным оставлять возможность использовать 60 GB ? Я лично считаю это непрофессиональным подходом.
// Я вижу для людей форум с двух сторон, одна сторона для тех кто хочет зайти и постебаться, а вторая для тех кто хочет обменяться информацией, т.е получить её или передать кому-то, так вот в моем случае первая сторона закончилась лет в 20 наверное, хотя период "постебаться" бесспорно был. Не воспринимайте сказанное на личный счет пока это не адресовано вам лично, а так же определитесь, с какой стороны вы видите форумы.... Я например готов делиться опытом что и делаю, а вы говорите что не хотите общаться, видимо по тому, что обмен информацией не интересен?
Т.е 300 метров это излишек уже? Понимаю что 3GB много, но опять же, опытным путем иду...
Да вы знаете , он пишет что и буфера 64MB недостаточно при условии что будет выделено 60 GB памяти от моих 32 :)
Это логично, но влияют на что, ограничение в 64 MB на запрос и общее количество кеша? Вопрос скорее в том, что может быть много запросов которые идут мимо кеша, но их то не решить такими настройками.
Нет, это вообще опасно.
Ну так вы же сами говорите что тюнер как бы не дает ничего, а просто анализирует и тут же предлагаете увеличивать значения по мере разговора с тюнером.... парадоксец простите.---------- Добавлено 06.02.2013 в 04:39 ----------
Вы указали 1.7 G, я поставил 2, на сколько я понимаю , это не отражается на:
"Maximum possible memory usage", как и время о котором вы говорите, для накопления информации по запросам - само собой, но для подсчета буферов - простите ....
Тому, что вы предлагаете настройки которые в реальности могут положить сервер.... не так? При достижении 600 конектов, где брать + 30 GB RAM ?
Вот именно, их меньше десятка, потому что mysql запущен 5 минут, а если посмотреть мой первый вывод mysqltuner, там где uptime составлял 8 часов, то будет понятно, что число 500 сессий достигается и не раз в течении суток, по этому сейчас когда 10, я очень рад этому )))) и вашим настройкам ))))) а в 12 часов дня мне надо будет нарисовать еще 30 GB памяти где-то ;))))) Это простите, как в php поставить memory_limit 10GB и молится что никто этого не заметит и не задействует :D Выглядит вяло....
// Фигня, в первом выводе не видно, но значение 600 взялось не спроста, при 500 , бывают ситуации в пиках когда too many connection .... так что расчет буферов производится из расчета 500-600 коyнектов.
В теории оптимизация должна зайти в такой момент когда mysql при 100% активности например убивает 60-70% ресурса сервера.... а дальше уже естественно будет проводиться работа по оптимизации запросов и доп. индексированию таблиц.....
// Что же касается "хостинга" то сервер "законсервирован", там не будет новых клиентов и ротации старых, по этому контент одинаков уже некоторое время, ну естественно за исключением обновлений которые касаются текущих клиентов, но они как бы не существенны, на 10 GB В день ни кто не ростет, движки 2 раза в день никто не меняет, собственно хочется понять и высчитать оптимальные значения для этой ситуации.
Согласен, его подбираем по размеру общему индексов, это значение так же уже было в фазе 2 и 3 GB, т.е с небольшим запасом.
Сейчас стоит 200 M, что это дает? Кстати, установка этих переменных не влияет на размер создаваемых временных таблиц.....
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_sort_buffer_size
Вот тут Пишут что: "On Linux, there are thresholds of 256KB and 2MB where larger values may significantly slow down memory allocation, so you should consider staying below one of those values."
Другими словами ставить "что попало" не имеет смысла, так как буфер будет выделяться даже в том случае если он не будет использован целиком. Почему взято значение 32 M ? поясните мне пожалуйста. Я понимаю, что документация не носит в себе настроек для всех и всяк, но хотелось бы кроме сухого ответа в виде 32M услышать ответ на вопрос "почему именно 32?"
Допустим, но влияет ли это на формирование нагрузки? ;)
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html
Интересная наводка: "It is better to keep the global setting small and change to a larger setting only in sessions that are doing large joins. Memory allocation time can cause substantial performance drops if the global size is larger than needed by most queries that use it."
Т.е по факту рекомендовано в глобальных значениях держать "некий минимум", а для сессий с большими join применять другое значение. Почему вы выбираете 64M ?
Это для : "Data in InnoDB tables: 29M (Tables: 58)" ???? 😮---------- Добавлено 06.02.2013 в 04:18 ----------
Сделали за меня что? Вы о чем? Комменнтарии это когда человек рассказывает почему стоит выбрать данное значение , а не говорит что это "базовая оптимизация" :) Базовая для чего и для кого ? :)
Я понял ваше настроение, спасибо что уделили время, приму ваши советы к сведению.
Обязательно подумаю на эту тему.---------- Добавлено 06.02.2013 в 04:25 ----------Кстати, при применении ваших настроек, результат mysqltuner выглядит вот так:
[!!] Maximum possible memory usage: 60.4G (192% of installed RAM)[OK] Slow queries: 0% (0/573)[OK] Highest usage of available connections: 0% (3/600)[OK] Key buffer size / total MyISAM indexes: 2.0G/1.7G[!!] Key buffer hit rate: 93.0% (40K cached / 2K reads)[OK] Query cache efficiency: 48.9% (258 cached / 528 selects)[OK] Query cache prunes per day: 0[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 32 sorts)[!!] Temporary tables created on disk: 40% (14 on disk / 35 total)[OK] Thread cache hit rate: 85% (3 created / 20 connections)[OK] Table cache hit rate: 87% (51 open / 58 opened)[OK] Open file limit used: 1% (101/8K)[OK] Table locks acquired immediately: 100% (326 immediate / 326 locks)[OK] InnoDB data size / buffer pool: 29.3M/50.0M
Полагаю сему виной как раз join_buffer_size 64M ?
Да без проблем, что он только даст , не совсем понимаю:
-------- General Statistics --------------------------------------------------[--] Skipped version check for MySQLTuner script[OK] Currently running supported MySQL version 5.1.66-cll[OK] Operating on 64-bit architecture-------- Storage Engine Statistics -------------------------------------------[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster[--] Data in MyISAM tables: 5G (Tables: 2512)[--] Data in InnoDB tables: 29M (Tables: 58)[--] Data in MEMORY tables: 0B (Tables: 12)[!!] Total fragmented tables: 141-------- Security Recommendations -------------------------------------------[OK] All database users have passwords assigned-------- Performance Metrics -------------------------------------------------[--] Up for: 8h 49m 32s (31M q [981.693 qps], 202K conn, TX: 109B, RX: 2B)[--] Reads / Writes: 94% / 6%[--] Total buffers: 796.0M global + 9.2M per thread (600 max threads)[OK] Maximum possible memory usage: 6.2G (19% of installed RAM)[OK] Slow queries: 0% (682/31M)[OK] Highest usage of available connections: 24% (148/600)[OK] Key buffer size / total MyISAM indexes: 512.0M/1.7G[OK] Key buffer hit rate: 100.0% (2B cached / 237K reads)[OK] Query cache efficiency: 29.0% (8M cached / 29M selects)[!!] Query cache prunes per day: 46333585[OK] Sorts requiring temporary tables: 0% (1K temp sorts / 475K sorts)[!!] Joins performed without indexes: 6944[!!] Temporary tables created on disk: 38% (237K on disk / 623K total)[OK] Thread cache hit rate: 99% (148 created / 202K connections)[OK] Table cache hit rate: 24% (3K open / 12K opened)[OK] Open file limit used: 62% (5K/8K)[OK] Table locks acquired immediately: 99% (23M immediate / 23M locks)[OK] InnoDB data size / buffer pool: 29.3M/50.0M-------- Recommendations -----------------------------------------------------General recommendations: Run OPTIMIZE TABLE to defragment tables for better performance MySQL started within last 24 hours - recommendations may be inaccurate Enable the slow query log to troubleshoot bad queries Adjust your join queries to always utilize indexes When making adjustments, make tmp_table_size/max_heap_table_size equal Reduce your SELECT DISTINCT queries without LIMIT clausesVariables to adjust: query_cache_size (> 32M) join_buffer_size (> 4.0M, or always use indexes with joins) tmp_table_size (> 200M) max_heap_table_size (> 200M)
Фрагментация - фигова, согласен, проведу optimize. еще?
Uptime не велик , но и не полчаса... С кешом игрался, можно чуток увеличить, но все равно значение в районе нескольких миллионов. Так как вижу NO_CACHE или как-то там запросы про процессам. Общий объем баз 5 GB, сайтов не много, но они посещаемые... Я полагаю для такого сервера 200 сайтов это не много :D :D :D Понимаю что "считать сайтами" не верно, но реально из них есть 5 которые по 50k+ uniq в сутки, остальные блекло смотрятся на их фоне, типа 1-5k uniq и даже меньше есть.... Рядом есть такой же сервер с практически такими же настройками но там иначе, тяжеловесов нет, но зато сайтов 1000+ чувствует себя в 100 раз лучше )))) полагаю что таки проблемы с запросами (базой).....
Еще думаю, что может совокупность факторов играет роль, например пишутся временные таблицы, тут же рядом может бекап запустится.... а следом уже комом набираются процессы php которые попросту не завершаются. и так по кругу пока есть свободный ресурс..... сейчас буферы немного увеличу по этой формуле:
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections
Что бы "Maximum possible memory usage:" было около 20 GB, я же понимаю это нормальным, для 32 гиг памяти.. ? остальные 13 останутся под все остальное, memory_limit и прочее в php есть, т.е выедать под ноль не должно.
Посмотрим как после этого пару суток вести себя будет ..... возможно перенос в shm решает вопрос в корне...хотя вы говорите что что-то настроили бы иначе... а точнее "Все..." , жду плотных комментариев :D
Тюнил и тут, причем от 100M до 3 GB и heap и table_size, пофик, результат тот же :D
А как же в таких случаях выживают хостеры? :) Таблички то ясное дело что не мои :D
Нету.
Какие моменты? Какие буферы маловаты на ваш взгляд?
Треш это а не софт, гоняю им, результата нет , показывает почти одно и то же, по буферам я сейчас специально урезал, что бы не более 10GB памяти кушало, ибо в моменты когда оно все заедает с сервером работать весьма сложно, но обращая внимание на график который я привел выше, возможно станет полегче из за переноса таблиц в shm.
Жестоки однако временные таблицы, смотрим график после переноса их на shm.
my.cnf выглядит вот так:
[mysqld] max_connections=600 safe-show-database local-infile=0 ## Cache query_cache_size=32M query_cache_limit=8M thread_cache_size=128 thread_concurrency=4 table_cache=4096 ## Buffers join_buffer_size=4M key_buffer_size=512M key_cache_division_limit=70 myisam_sort_buffer_size=64M key_buffer=16M sort_buffer=3M tmp_table_size=200M max_heap_table_size=200M interactive_timeout=600 wait_timeout=30 connect_timeout=20 innodb_buffer_pool_size=50M ### max_join_size=5000000000 max_sort_length=512 key_buffer_size=512M myisam_sort_buffer_size=32M read_buffer_size=1M read_rnd_buffer_size=1M
При этом логи веб сервера занимают около 500 MB , это те которые актуальны , естественно они ротируются.
MySQL ведет только error log, который весит около 2х метров :D
Вопрос про tmp таблицы актуален, машинка оснащена 32 гигами памяти.... почему временные таблицы выпадают на диск?---------- Добавлено 06.02.2013 в 01:59 ----------Перенес в shm временные таблицы, сервер конечно отпустило но понятно как бы почему, вопрос остается открытый, мне не ясно почему SQL пишет на диск если есть свободная память.... (с точки зрения временных таблиц). Винт у меня разбит на "/" и "/tmp", раньше писало в /tmp , отдельный раздел, меньше вопросов было, но со временем отрезанного (не LVM) под /tmp стало не хватать, перенесли в "/" этим собственно и добили. Сейчас в shm с меньшим i/o пишет конечно, но *****, почему не сразу в память? Какие буфера крутить ? куда? :)
Тот тариф о котором вы пишите действует, вот условия: https://onyx.net.ua/hid.2.0.1.2.php
Что значит мануалы? Какие мануалы? После регистрации вам будет направлено письмо с техническими параметрами доступа к cPanel, DNS информацией и прочим, как работать с cPanel изложено в очень обширной документации на сайте самой cPanel (www.cpanel.net). Или о каких мануалах речь?
