zloj: Может ли это быть из за MySQL? У меня все базы в innodb, файл ibdata1 весит 4 с лишним гига а базы около двух вроде.
Конечно может, ровно как и из за любого другого демона....
Судя по df -h у вас не смонтирован shm ? Перенесите временные таблицы в SHM, чуток отпустит MySQL , но надо будет памяти IMHO в тазик добавить чуток.... Ибо там по TOP вашему виднеется 200 MB в свопе .... Стало быть ..... мало памяти?
и я бы max_connections=86 ибо 150 вы не вытягиваете и примерно.
Чертовски классная формула, но не понимаю чем она помогает \ мешает в данном случае, у него же и при 150 коннектах максимальная память в приделах нормы.... то что завышено число коннектов и как следствие выделяется избыточное количество памяти под буфера - это конечно плохо, но мало вероятно что это хоть как-то отражается на проблеме которая существует.
---------- Добавлено 07.05.2013 в 16:52 ----------
Melanxolik: Тут не такая большая нагрузка и проблема явно в другом чтобы углублятся в прокси и всякие другие прослойки.
Вот вот, я о том же.... сильно мало там движения что бы создавать какие-то проблемы.... ))) у меня maxmem например при текущих настройках будет в районе 20-25 GB ... :))) У ТС-а вообще 2 гига памяти, что там ворочать можно то... тут что-то более интересное, я пока склонен полагать что или аппаратные приколы с сетевкой и таки бочинит TCP/IP ну или магия :D
michaek: ни разу с таким не встречался. обычно по времени одинаково. да и 2 суток против 2 часов? это что за диски такие, где запись в 24 раза медленнее чтения?
Нет, просто полагаю, что консистенцию проверять это одно дело, а копировать данные с винта на винт другое... не более того, процесс чека в любом случае должен топать быстрее процесса синка... хотя бы по тому, что там чтение , а там запись.... может оно конечно и не в 24 раза, но обращал внимание у себя на центосах, если случился вдруг холодный ребут ... это ребилд рейда как полагается, а при длительном аптайме проходит чек который завершается в раз быстрее, но это только наблюдения, замеров точных не делал, может быть там разницы и пару часов.... Подождем пока ТС проснется и напишет сколько там уже :D
michaek: разница в том, что при sync идет запись на некоторые диск(и), при check идет только чтение. на работающей под нагрузкой системе обычно и тот, и другой процессы сваливаются в минимальную скорость. или я как-то неправильно вопрос понял?
Ну т.е запись никак не медленней чем просто чтение ? :) Я имел ввиду что реконструкция под нагрузкой может занять например 2е суток как писало там выше, а обычный check проскочит за пару часов..... если там конечно нарушений структуру не будет серьезных и не придется таки в режим sync переходить :)
bugsmoran: Это опасная игра. Да, Unix-сокеты быстрее TCP-сокетов (кстати не вот прям значительно), но они могут отлететь при нагрузке (например на них влияет ограничение на количество открытых дескрипторов).
Я предлагаю попробовать, так как не ясно какие могут быть оборванные коннекты при работе с локальной тачкой ?:)
bugsmoran:
К слову, у библиотеки php-mysql есть одна недокументированная особенность: если человек в своем сайте указывает сервер "localhost", то подключение пойдет по Unix-сокету, а если указывает "127.0.0.1" - то по TCP :) Вот такой вот неожиданный поворот событий! Получается, что производительность зависит от клиентов хостинга даже.
Ну особенность известная..... в соответствующих кругах... :D :D
Тогда точно ждите окончания ребилда, после этого можно будет о чем-то говорить более предметно ..... а пока вся ваша загрузка легко списывается на ребилд винтов.... Кстати, у вас какой-то монитор есть на эту тему? Возможно у вас из md устройства по какой-то причине периодически винт выпадает?
Хотя у вас там "check" написано, по моему если синкается то пишет sync: ? может просто очередная проверка целостности, оно не закончилось еще?
zloj, ну если вы их лечите .... путем ребута сервера, то у вас может и рейд уже месяц собирается, как же тут понять то, сейчас вполне нормально и должно тормозить, так как идет синхронизация вашего raid-1 т.е копируются данные ровно как и на первом винте, по этому рост WA в данном случае является нормальным. По концепции я бы рекомендовал дождаться , пока рейд закончит синхронизацию, а потом бы уже смотрел тормозит или нет..... В момент ребилда рейда тормозить может так что у вас WA будет и 80 и 90 % легко.... от винтов многое зависит.
Смарты ваши на первый взгляд чистые .... 12 тысяч часов наработки у винтов, поставлены одновременно (разница всего 1 час)... Ремапов нет, стало быть винты в норме.... Кстати, а можно еще результат df -h увидеть, а то я редко вижу что бы через mdadm нарезали столько разделов :D понять бы что там у вас к чему, может у вас параллельно с ребилдом рейда еще и данные заливаются в какойнить /storage ? ведь 3 TRB видать не с проста? :)
Кстати, на скорость синхронизации вроде как влияет еще:
sstyle: спасибо почитаю. Удаленных нет, я выше отвечал.
Снимаю шляпу, недочитал, тогда еще вопрос, у вас конект по TCP или socket ?
Если TCP... попробуйте поменять на socket... хотя если у вас ВПС как говорится... проблемы могут быть и снаружи окружения, а ВПС уже тупит скажем так по своему в эти моменты..... У меня за несколько месяцев 0% обрывов ....... при этом у меня частично открыт SQL в мир.... (но это дедик)
Может ли это быть из за MySQL? У меня все базы в innodb, файл ibdata1 весит 4 с лишним гига а базы около двух вроде.
Конечно может, ровно как и из за любого другого демона....
Судя по df -h у вас не смонтирован shm ? Перенесите временные таблицы в SHM, чуток отпустит MySQL , но надо будет памяти IMHO в тазик добавить чуток.... Ибо там по TOP вашему виднеется 200 MB в свопе .... Стало быть ..... мало памяти?
maxmem = key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections
и я бы max_connections=86 ибо 150 вы не вытягиваете и примерно.
Чертовски классная формула, но не понимаю чем она помогает \ мешает в данном случае, у него же и при 150 коннектах максимальная память в приделах нормы.... то что завышено число коннектов и как следствие выделяется избыточное количество памяти под буфера - это конечно плохо, но мало вероятно что это хоть как-то отражается на проблеме которая существует.
---------- Добавлено 07.05.2013 в 16:52 ----------
Тут не такая большая нагрузка и проблема явно в другом чтобы углублятся в прокси и всякие другие прослойки.
Вот вот, я о том же.... сильно мало там движения что бы создавать какие-то проблемы.... ))) у меня maxmem например при текущих настройках будет в районе 20-25 GB ... :))) У ТС-а вообще 2 гига памяти, что там ворочать можно то... тут что-то более интересное, я пока склонен полагать что или аппаратные приколы с сетевкой и таки бочинит TCP/IP ну или магия :D
ни разу с таким не встречался. обычно по времени одинаково. да и 2 суток против 2 часов? это что за диски такие, где запись в 24 раза медленнее чтения?
Нет, просто полагаю, что консистенцию проверять это одно дело, а копировать данные с винта на винт другое... не более того, процесс чека в любом случае должен топать быстрее процесса синка... хотя бы по тому, что там чтение , а там запись.... может оно конечно и не в 24 раза, но обращал внимание у себя на центосах, если случился вдруг холодный ребут ... это ребилд рейда как полагается, а при длительном аптайме проходит чек который завершается в раз быстрее, но это только наблюдения, замеров точных не делал, может быть там разницы и пару часов.... Подождем пока ТС проснется и напишет сколько там уже :D
разница в том, что при sync идет запись на некоторые диск(и), при check идет только чтение. на работающей под нагрузкой системе обычно и тот, и другой процессы сваливаются в минимальную скорость. или я как-то неправильно вопрос понял?
Ну т.е запись никак не медленней чем просто чтение ? :) Я имел ввиду что реконструкция под нагрузкой может занять например 2е суток как писало там выше, а обычный check проскочит за пару часов..... если там конечно нарушений структуру не будет серьезных и не придется таки в режим sync переходить :)
не должен ) но что-то типа echo 200000 > /sys/block/md2/md/sync_speed_min поможет ускорить оба процесса
хммм.... простите в чем же тогда разница? :)
это не ребилд, да, верификация. отменить можно через
Ага, сразу не придал этому значения, кстати "check" должен как бы быстрее топать нежели "sync" , а то там 2 дня написано ждать :D
Это опасная игра. Да, Unix-сокеты быстрее TCP-сокетов (кстати не вот прям значительно), но они могут отлететь при нагрузке (например на них влияет ограничение на количество открытых дескрипторов).
Я предлагаю попробовать, так как не ясно какие могут быть оборванные коннекты при работе с локальной тачкой ?:)
К слову, у библиотеки php-mysql есть одна недокументированная особенность: если человек в своем сайте указывает сервер "localhost", то подключение пойдет по Unix-сокету, а если указывает "127.0.0.1" - то по TCP :) Вот такой вот неожиданный поворот событий! Получается, что производительность зависит от клиентов хостинга даже.
Ну особенность известная..... в соответствующих кругах... :D :D
Тогда точно ждите окончания ребилда, после этого можно будет о чем-то говорить более предметно ..... а пока вся ваша загрузка легко списывается на ребилд винтов.... Кстати, у вас какой-то монитор есть на эту тему? Возможно у вас из md устройства по какой-то причине периодически винт выпадает?
Хотя у вас там "check" написано, по моему если синкается то пишет sync: ? может просто очередная проверка целостности, оно не закончилось еще?
zloj, ну если вы их лечите .... путем ребута сервера, то у вас может и рейд уже месяц собирается, как же тут понять то, сейчас вполне нормально и должно тормозить, так как идет синхронизация вашего raid-1 т.е копируются данные ровно как и на первом винте, по этому рост WA в данном случае является нормальным. По концепции я бы рекомендовал дождаться , пока рейд закончит синхронизацию, а потом бы уже смотрел тормозит или нет..... В момент ребилда рейда тормозить может так что у вас WA будет и 80 и 90 % легко.... от винтов многое зависит.
Смарты ваши на первый взгляд чистые .... 12 тысяч часов наработки у винтов, поставлены одновременно (разница всего 1 час)... Ремапов нет, стало быть винты в норме.... Кстати, а можно еще результат df -h увидеть, а то я редко вижу что бы через mdadm нарезали столько разделов :D понять бы что там у вас к чему, может у вас параллельно с ребилдом рейда еще и данные заливаются в какойнить /storage ? ведь 3 TRB видать не с проста? :)
Кстати, на скорость синхронизации вроде как влияет еще:
/proc/sys/dev/raid/speed_limit_max
/proc/sys/dev/raid/speed_limit_min
Поиграться можно с этими параметрами.
спасибо почитаю. Удаленных нет, я выше отвечал.
Снимаю шляпу, недочитал, тогда еще вопрос, у вас конект по TCP или socket ?
Если TCP... попробуйте поменять на socket... хотя если у вас ВПС как говорится... проблемы могут быть и снаружи окружения, а ВПС уже тупит скажем так по своему в эти моменты..... У меня за несколько месяцев 0% обрывов ....... при этом у меня частично открыт SQL в мир.... (но это дедик)