|
|
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
Есть Дебиан сервер 32гб оперативной памяти. На нем же стоит апач2 и нжинкс. Нагрузка постоянно высокая. Иногда заканчивается память, хотя апач настроен только на 70 клиентов. Остальные сервисы (мемкешед например) не используют много памяти. Когда нагрузка на пределе мускул останавливается. Я наблюдаю, что запросы спят и растет число подключений до максимума. Мускул настроен использовать 24 гб памяти максимум. В базе есть таблицы InnoDB с большим размером (больше 30гб, 400000 записей). Так же на сервере есть многопоточное приложение, которое осуществляет запись. Поэтому выбран InnoDB. Вот мой конфиг Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. Помогите сделать базу стабильной. Использование памяти Код: sql 1. 2. 3. 4. 5. Как видно моя проблема не в памяти, т.к. свободно 20 гб. Каждый день утром база встает. Что это может быть? Я пользуюсь mysqltuner и tunung-primer.sh. Mysqltuner output Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. Mysql primer output Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2013, 14:29:10 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
автор[!!] Joins performed without indexes: 106025 [!!] Temporary tables created on disk: 49% (351K on disk / 715K total) [!!] InnoDB data size / buffer pool: 39.4G/5.9G авторМускул настроен использовать 24 гб памяти максимум. чет ты не то насторил ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2013, 14:32:58 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
ScareCrowавтор[!!] Joins performed without indexes: 106025 [!!] Temporary tables created on disk: 49% (351K on disk / 715K total) [!!] InnoDB data size / buffer pool: 39.4G/5.9G авторМускул настроен использовать 24 гб памяти максимум. чет ты не то насторил Поменял в конфиге еще вот эти значения Код: sql 1. 2. 3. 4. 5. 6. Мне нужно увеличить join_buffer_size ? Но тюнер не рекомендует делать его больше 5мб. Temporary tables created on disk: 49% - у меня много записей с BLOB, для них эта настройка не актуальна. InnoDB data size / buffer pool: 39.4G/5.9G - увеличен до 8 гб. Можно больше? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2013, 14:36:58 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
поднять innodb_buffer_pool_size = 5000M slow query log показывай. запросы у которых джойны не по индексам показывай. авторmyisam_sort_buffer_size = 400M о господи, зачем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2013, 14:37:28 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
авторOf 366426 temp tables, 49% were created on disk запросы кривые, да. показывай лучше их. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2013, 14:40:07 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
ScareCrow, innodb_buffer_pool_size установлен в 8гб. Сделать больше? myisam_sort_buffer_size = 400M Понятия не имею. :) Сколько поставить? MyISAM использует другая база на том же сервере. Тоже не маленькая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2013, 14:41:09 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
myisam_sort_buffer_size = 256M Сделал так, почитал на percona, действительно много. slow-log сейчас скачаю на локалку, предварительно увидел там 2 запроса, которые повторяются чаще всего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2013, 14:48:17 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Код: sql 1. 2. И еще пара запросов, которые просто оперируют большим объемом данных, например большой массив в serialize. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2013, 15:05:33 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
а планы этих запросов? а DDL таблиц? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2013, 15:06:01 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
По запросам пройдутся программисты. Подскажите больше по конфигурации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2013, 15:07:35 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
авторКаждый день утром база встает. Что это может быть? Это нормальная физиологическая реакция на раздражение мочеполовых путей. попробуйте не пить на ночь много жидкости. А если вы хотели узнать что происходит с ПО mysql, то опишите этот процесс нормально. Что не работает, какие сообщения об ошибках видите и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2013, 15:08:11 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
seyferПо запросам пройдутся программисты. Подскажите больше по конфигурации. Раз вы не программист - ничего не трогайте. Дайте людям спокойно оценить ситуацию, подумать и поработать. Перетасовка конфигов администраторами без понимания сути всегда приводит к какой-нибудь фигне. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2013, 15:09:56 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
netwind, если вы не будете придираться к конкретно этой фразе, и все такие прочитаете все остальное, то там все описано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2013, 15:10:06 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
netwind, я как раз таки ведущий разработчик. у меня другие задачи в отделе сейчас. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2013, 15:10:33 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
seyfer, я и прочитал все. >Когда нагрузка на пределе мускул останавливается. Я наблюдаю, что запросы спят и растет число подключений до максимума. Так не бывает. Вам просто кажется. Обычно есть возможность подключиться от root и выполнить show processlist; потому что так задумано ( http://dev.mysql.com/doc/refman/5.1/en/too-many-connections.html) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2013, 15:15:11 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
seyfer, понятно, что пока ситуация не повторится, понять чем именно занимается mysql нельзя. Какой-нибудь мониторинг параметров mysql есть ? Логи mysql фиксируют т.н. dedlock-И ? Придется поставить мониторинг, потому что гадать можно долго. Стандартные графики от munin анализируют show processlist и по графикам можно уже предположить произошла ли блокировка или они просто так активно потребляли ресурсы, что друг-друга "задушили". Попробуйте все-таки уменьшить tmp_table_size до адекватных и вынести tmp_dir в tmpfs. Хотя непосредственных причин делать это не вижу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2013, 15:24:57 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
netwind, tmp_table_size - адекватное, это сколько? Я мониторю через workbeanch с убунты, выполняет тот же show process list , только в GUI. И я наблюдаю именно то, что наблюдаю. При это число запросов растет, т.к. демон их посылающий продолжает работать, до исчерпания лимита подключений. Сам процесс mysql не останавливается, он продолжает "висеть", только ни одного запроса не выполняется, query все в состоянии sleep и с течением времени сам по себе сервер не разгружается. Только перезагрузка mysql спасает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2013, 06:24:19 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
seyfer, 0. Оптимизация таблиц БД. Проще всего сделать полный дамп, остановить Мускуль и перезалить всё из дампа "на чистую". Не представляю как вручную найти 344 таблицы, требующих оптимизации. Возможно есть смысл отказаться от постоянных соединений с Мускулем... 1. Поставьте критическое время и смотрите лог медленных запросов. Это первое. Там по-хорошему не должно быть НИЧЕГО при заданном пороге. Совсем ничего. Каждый запрос, анализируйте на предмет ширины выборки (а надо ли всё), количества записей и главное - наличие индексов. Как только, ваши программисты оптимизируют всё, двигаемся дальше. В этом же пункте должно уйти "джойны без индексов"... 2. Смотрите на создание временных таблиц на диске. Этого тоже не должно быть совсем, если по-хорошему. Перестраивайте логику запросов и ХП так, чтобы всё работало в оперативе. Тем более у вас её "хоть ...опой". Как только ваши программисты решат этот вопрос, двигайтесь дальше. 3. Смотрите статус иннодебила на предмет блокировок, ломанных индексов и т.д. 4. Только после выполнения п0-3 начинайте играться с параметрами Мускуля по оптимизации. ИМХО: классический Г-код, с вполне ожидаемыми последствиями. Программистов, во главе с главным - бить по рукам рублем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2013, 06:39:28 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
Arhat109seyfer, 0. Оптимизация таблиц БД. Проще всего сделать полный дамп, остановить Мускуль и перезалить всё из дампа "на чистую". Не представляю как вручную найти 344 таблицы, требующих оптимизации. Возможно есть смысл отказаться от постоянных соединений с Мускулем... 1. Поставьте критическое время и смотрите лог медленных запросов. Это первое. Там по-хорошему не должно быть НИЧЕГО при заданном пороге. Совсем ничего. Каждый запрос, анализируйте на предмет ширины выборки (а надо ли всё), количества записей и главное - наличие индексов. Как только, ваши программисты оптимизируют всё, двигаемся дальше. В этом же пункте должно уйти "джойны без индексов"... 2. Смотрите на создание временных таблиц на диске. Этого тоже не должно быть совсем, если по-хорошему. Перестраивайте логику запросов и ХП так, чтобы всё работало в оперативе. Тем более у вас её "хоть ...опой". Как только ваши программисты решат этот вопрос, двигайтесь дальше. 3. Смотрите статус иннодебила на предмет блокировок, ломанных индексов и т.д. 4. Только после выполнения п0-3 начинайте играться с параметрами Мускуля по оптимизации. ИМХО: классический Г-код, с вполне ожидаемыми последствиями. Программистов, во главе с главным - бить по рукам рублем. Конструктивно. 0. Прогнал сегодня ночью mysqloptimize утилиту по всем базам. Делалась долго, но почему-то после перезапуска базы тюнер снова говорит, что дефрагментировано 300 баз. Я тут в замешательстве, я же только что прогнал оптимизацию. 1. По логам уже с подачи товарища выше прошлись, запросы оптимизированы. Все же проблема скорее всего на уровне системы или железа. 2. Тут, к сожалению, нет такого опыта. Чтобы не создавались временные таблицы рекомендуется увеличивать параметр temp_table_cache и open_file_limit. При увеличении все равно 50%, т.к. у нас используются BLOB поля, такие таблицы не записываются в память. Как иначе? 3. Мониторинг workbeanch выполняется. Таких проблем не обнаружено. 4. Вот мы и пришли к этому пункту и я написал на форум. Бить никого не надо. Надо помогать. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2013, 06:50:56 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
seyfer, tmp_table_size конечно же. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2013, 06:51:54 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
seyfer, "как всё запущено"... :) 1. "Чукча не читатель". Перечитайте п.1. по буковкам... сделать дамп и загрузить его заново. Это долго... может быть очень долго... но это позволит гарантировать файловую оптимизацию таблиц. По сути "снести всё и поставить базы заново, записав их последовательно на диск"... 2. "Чукча не читатель2". За одно только SELECT t.* и BLOB поля - всех прогеров можно в 80% случаев увольнять без выходного пособия, а первым - ведущего разработчика. Должно быть строгое(!) обоснование применимости широкой выборки и тем более хранении blob полей... оно есть, точно? Расскажете зачем? 3. следствие п.2. Временные таблицы... они ваще зачем в явном виде?!? ЭТО ОБОСНОВАНО? А ежели в неявном, то тем более надо гнать метлой. Смотрите запросы... там точно надо джойнить всю таблицу, без этого никак? 4. Ну хоть тут ровно... Ещё раз: ваше приложение требует глубокой оптимизации запросов к Мускулю. Тюнинг настроек надо делать ПОСЛЕ неё. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2013, 07:38:44 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
seyfer, и вас есть бригада на 10 человек и мешки для перетаски, одни человек - один мешок за одну минуту. Если мешки подвозят под разгрузку развномерно до 9 в минуту - все ок, если больше, то бригада встает ибо новые мешки засыпают все вокруг и бригада встет.... или ложится... Путем подкрутки сервера вы добавите еше двух человек в бригаду и замените резиновую плетку погоншика на настояшую кожаную. ВЫ добьетесь произовдительности 14 мепков в минуту, на 40% больше. Но привезут 15 шеков и все встанет. Нельзя с таким запасом работать. ***************** Прислушайтесь к предыдушим ораторам и подойдите к проблеме со стороны запросов. Если вы хотите чтоб база хоть как-то дышала, то УМЕНЬШИТЕ количество соединений и УМЕНЬШИТЕ тимеоуты. Поставьте не 200 а 40 --- если не будет падать база, то 80. По крайней мере часть запросов с ПО будет проходить нормально. Количество конекций хорошо бы сунхронизировать с тредами-воркерами в нжиксе и в апаче. Если конекции без вывертов, то один-к-одному вполне нормально. То что вы привели в качестве примера из слоу-квери-лога -- очень неуклюжий код с повторами -- очевидно сгенерированый так-себейным кверигенератором. Вам придется найти опытного специалиста разгрести ... при чем НЕ этот конкретный код а как минимум на парочку уровней выше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2013, 07:43:32 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
seyfer, Для понимания, приведите эксплейн первого выданного вами запроса или его теперешней модификации, заодно и КАК изменили... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2013, 07:44:20 |
|
||
|
High Load mysql on Debian server - падает каждый день, почему?
|
|||
|---|---|---|---|
|
#18+
Arhat109, BLOB для очень больших объемов данных. Есть цельные данные, такие как xml и массивы, они сжимаются COMPRESS, так и хранятся в BLOB. Предложите решение лучше для больших данных. (только не надо предлагать no-sql базы). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2013, 07:46:15 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38313527&tid=1836478]: |
0ms |
get settings: |
9ms |
get forum list: |
21ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
73ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
| others: | 224ms |
| total: | 388ms |

| 0 / 0 |
