Isp глубоко на своих пользователей, так что... багом больше, багом меньше.
Достаточно посмотреть на политику их продуктов. Перестали покупать значит надо клепать новую версию и все старые обязательно надо заморозить.
К сожалению это называется: бизнес по русски.
>В нормальном варианте клиент выбирает уровень срочности своего запроса.
Издеваетесь?
Любой простой вызывает очень бурные эмоции.
Ну честно, сервер диагностика за 5-10 минут после обращения.
Дальше по ситуации, худшие события: мгновенно перебросились hdd и клиент снова работает до решения проблемы или hdd клиента дампится на новый и все снова в строю.
В каждом варианте есть свои решения, но почему-то клиент не думает когда заказывает, а только задумывается когда возникает простой.
Просто тут многое зависит от отношения хостера и того как построена система, в идеале простой будет вызван двумя вещами: разворачиванием конфига виртуальной машины и поднятием backup со стороны клиента или хостера, в среднем до часа в сумме.
cache_limit опустите до 4-х мегабайт.
temp_tables еще надо тюнить. не все вытащили.
max_connections тоже можно подрезать до 48ми.
а так красиво.
но дело в том что mysqltunner и tunning-premier друг друга дополняют, чтобы ими пользоватся надо понимать как работает система.
да, tunning-premier не всегда работает и не везде.
банальный вопрос, tcpdump с обоих концов, размеры пакетов и checksum совпадают?
такое поведение может быть вызыванно из-за фрагментации пакетов, где-то она или обрезана или перекручена.
так что анализ сети и только потом все остальное.
А что у него может быть:
[--] Data in MyISAM tables: 4G (Tables: 1957)
[--] Data in MEMORY tables: 762K (Tables: 6)
)
[!!] Joins performed without indexes: 137119
Индексы, не неслышал.
[--] Reads / Writes: 75% / 25%
[--] Total buffers: 234.0M global + 8.9M per thread (150 max threads)
Оптимизация на чтение, не неслышал.
До сети еще доберемся, пока это пусть в чувство приведет.
Благо советов дали огого.
table_open_cache = 1024
table_definition_cache=1024
увидил, лучше изменить на:
table_open_cache = 2048
table_definition_cache=2048
ну да, на сервере ведь 2Гб озу, значит 2Гб должен забрать под себя мускуль.
D:
Тут не такая большая нагрузка и проблема явно в другом чтобы углублятся в прокси и всякие другие прослойки.
sort_buffer_size = 2M
read_buffer_size = 1M
read_rnd_buffer_size = 1M
query_cache_size = 128M
query_cache_type=1
query_cache_limit=2M
log-slow-queries = /var/log/mysql/slow-query.log
log-queries-not-using-indexes
tmp_table_size=512M
myisam_sort_buffer_size=8M
mkdir /var/log/mysql
chown mysql:mysql /var/log/mysql
но тут надо смотреть что выдает max mem, так как:
maxmem = key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections
и я бы max_connections=86 ибо 150 вы не вытягиваете и примерно.
ну а дальше смотреть что у вас в логах и с индексами, explain вам в руки.
Myski, о, и вы тут, приятно, узнал.
dmg.shark, я бы попробовал вам объяснить про замену диска, но думаю это будет бесполезно, в случае Myski делать копию данных уже было бесполезно, в вашем же случае при замене дисков у вас все до единого файла остались на своих местах, чувствуете разницу?
так вот, на полное зеркалирование данных в среднем уходит 1.5 часа, берите расчет 500гб, по 80-120мб в секунду при блоке в 512К.
Как уже сказал, я ошибся в решении когда согласился вам помочь с вашими проблемами, а замена дисков на более производительные была в обще самой большой ошибкой, ну что поделаешь, на спасибо уже заработал, но отношение ко многим вопросам поддержки пользователей буду вынужден пересмотреть чтобы не тратить больше своего личного времени.
на сим откланяюсь и дальнейший диалог продолжать не собираюсь.
