|
|
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
Друзья, добрый день! Помогите, пжлста, не можем понять в чём дело. Есть INNODB-база, размером 6Gb. На сервере практически ничего, кроме базы нет. Размер оперативной памяти -- 16Gb. Всё работало нормально, с недавних пор база начала жутко тормозить и вешать сервер, примерно вот так: Код: powershell 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Вот что показывает mytop: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. В топе самые разные запросы, время выполнения везде нулевое. Вот my.cnf: Код: 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. Mysqltuner показывает вот что: Код: 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. И вот ещё статус mysql: Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2014, 21:35:02 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
Готовы заплатить за оперативное решение проблемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2014, 21:35:42 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
во временном каталоге (обычно /tmp) что происходит? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2014, 22:23:56 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
Что попадает в mysql-slow.log ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2014, 22:28:08 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
kayuchkin Код: sql 1. Основная проблема мне видится здесь. Что-то произошло, и временные таблицы стали сваливаться на диск. Вспоминайте, что менялось непосредственно перед тем, как возникла проблема. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2014, 22:37:34 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
kayuchkinГотовы заплатить за оперативное решение проблемы. ds, хоть емейл открыли ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2014, 00:03:51 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
miksoftkayuchkin Код: sql 1. Основная проблема мне видится здесь. Что-то произошло, и временные таблицы стали сваливаться на диск. Вспоминайте, что менялось непосредственно перед тем, как возникла проблема. на моё имхо вряд ли. автор Highest connection usage: 100% (101/100) я тупо за ддос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2014, 00:05:33 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
авторHighest connection usage: 100% (101/100)На мой взгляд это следствие того, что "Temporary tables created on disk: 48%". (пока отрабатывает один запрос, успевают набежать еще несколько). По крайней мере, не наоборот. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2014, 00:31:17 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
kayuchkin, 1. По первой картинке явственно следует что сервак тупо не справляется с нагрузкой. Особых проблем с IO операциями ФС - явно нет. 2. СВОП файл от ОС - не используется, что говорит о достатке оперативы. 3. По тюнеру: а) он прямо утверждает, что нехватает threads. б) недостаточен кеш определений таблиц. в) при избыточном буфере для иннодебилового кеша (8G при используемых 2.2G) г) недостаточно оперативы для временных таблиц. 48% записи на диск - это многа. Ну и из настроек бросается в глаза очень небольшой Join-buffer... не из-за этого создаются "времянки на диске"? Ну и похоже, что дисковая подсистема сервера - явно слабовата. У вас в основном чтение. Поставьте нормальные серверные винты, хотя бы 2шт в raid1 и получите скорость чтения ФС от 240метров в секунду, вместо 60-80. Возможно проблема в ДДОС, или его имитации. Тупо сервер не держит столько коннекций по другим местам и каждый запрос требует много мелких обращений к Мускулю ... кстати, там случаем Мускуль не настроен ДНС-ы искать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2014, 07:29:16 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
Коллеги, спасибо! Если кто-то готов взяться за решение проблемы с оплатой за результат -- пишите на kayuchkin@gmail.com ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2014, 10:13:51 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
В джентльменский набор вопрошающего нужно еще включить pt-summary или даже pt-mysql-summary. Он хотя бы приблизительное представление об конфигурации железа дает. А тут особо халявы нет. Никто еще не смог парой параметров серьезно ускорить mysql. Ну разве что innodb_flush_log_at_trx_commit, но там уже 0. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2014, 17:21:01 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
А хотя тут еще freebsd. Не уверен даже что скрипт для этой умирающей экзотики правильно выдаст конфигурацию оборудования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2014, 17:28:27 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
miksoftkayuchkin Код: sql 1. Основная проблема мне видится здесь. Что-то произошло, и временные таблицы стали сваливаться на диск. Вспоминайте, что менялось непосредственно перед тем, как возникла проблема. А это ? Код: sql 1. не волнует ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2014, 22:58:46 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
MasterZivА это ? Код: sql 1. не волнует ?я уже отвечал на это - 17026534 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2014, 23:00:36 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
miksoftMasterZivА это ? Код: sql 1. не волнует ?я уже отвечал на это - 17026534 У них проблема скорее всего в авторПомогите, пжлста, не можем понять в чём дело . У них затык вообще в приложении, а они думают, что БД виновата. ТС, 1) включите slow query log. Гуглите прямо так "mysql slow query log". 2) Увеличте максимальное число коннекций к БД. Процентов на 50 для начала. Тут http://dev.mysql.com/doc/refman/5.5/en/too-many-connections.html сказано как. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2014, 23:15:56 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
MasterZivУ них затык вообще в приложении, а они думают, что БД виновата.в БД тоже не все гладко, как минимум. По 2 временных файла на диске каждую секунду в среднем - это все-таки не мало. Если они хотя бы по сотне-другой мегабайт, то могут полностью утилизировать пропускную способность дисковой подсистемы.MasterZiv1) включите slow query log. Гуглите прямо так "mysql slow query log".Он включен. Вопрос о содержимом лога был. Ответа не было. MasterZiv2) Увеличте максимальное число коннекций к БД. Процентов на 50 для начала.А смысл? ну встанут еще 50 сессий в очередь за ресурсами, которых нет, а толку-то? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2014, 23:30:16 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
miksoft, Да, тоже сколоняюсь к моменту о времянках. Там получается на каждый запрос к серверу-клиента (PHP?) создается примерно по 2 времянки, из которых 1 - похоже лезет на диск "всяко". Ещё смушает 17 фрагментированных таблиц... Да, slow log очень бы было полезно глянуть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2014, 11:39:59 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
Arhat109Там получается на каждый запрос к серверу-клиента (PHP?) создается примерно по 2 времянкиА выделенное откуда следует? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2014, 11:48:09 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
miksoft, Up for: 1d 13h 55m 1s (47M q [346.190 qps], 280K conn и Temporary tables created on disk: 48% (246K on disk / 510K total ) примерно 1 к 2. Не? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2014, 12:59:36 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
ребята, надо искать конкретику. "сервер тормозит" - это не проблема. надо брать самый тормозящий запрос и тюнить. потом брать следующий и тюнить. и так до тех пор, пока все не будет работать хорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2014, 13:28:36 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
MasterZivребята, надо искать конкретику. "сервер тормозит" - это не проблема. надо брать самый тормозящий запрос и тюнить. потом брать следующий и тюнить. и так до тех пор, пока все не будет работать хорошо. сразу видно с вебом вы не сталкивались. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2014, 13:32:44 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
ScareCrowMasterZivребята, надо искать конкретику. "сервер тормозит" - это не проблема. надо брать самый тормозящий запрос и тюнить. потом брать следующий и тюнить. и так до тех пор, пока все не будет работать хорошо. сразу видно с вебом вы не сталкивались. да абсолютно все равно, web там или что. бд запросы выполняет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2014, 13:35:24 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
ScareCrowMasterZivребята, надо искать конкретику. "сервер тормозит" - это не проблема. надо брать самый тормозящий запрос и тюнить. потом брать следующий и тюнить. и так до тех пор, пока все не будет работать хорошо. сразу видно с вебом вы не сталкивались. А в "моем" вебе эта техника нормально работает. Да и чего бы ей не работать, если люди думают и ошибаются примерно одинаково ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2014, 13:39:25 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
Коллеги, добрый день! большое спасибо за ваши ответы и советы! По поводу "брать каждый запрос и тюнить": Мы давно и достаточно долго оптимизировали структуру базы и запросы, проверяли что везде используются нужные индексы и т.д. Более того, этот проект ( http://puzzleit.ru) существует уже несколько лет, до этого он крутился на одном сервере при посещаемости около 200-300 просмотров страниц в сутки, сервер справлялся вообще без напрягов, проблем не было. Недавно перенесли базы на отдельный сервер (он у нас пустовал -- такой же конфигурации, в этом же дата-центре, только оперативной памяти вдвое больше). После этого начались проблемы с базой. Очевидно, что проблема где-то в неправильной настройке базы или сервера, а не в неоптимизированных запросах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2014, 18:58:42 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
Дополню по результатам просмотра на серверах: 1. С фряхой последний раз общался году в 93-м, поэтому нифига не помню где там и что ... не судить строго. 2. На обоих серверах стоит Мускуль, slow log есть и там и там, но с разным размером и датой: На "основном серваке puzzleit.ru - он большой 366.7М от 21.12 03:10, а на серваке с БД - "маленький" 1.4М от 21.12 20:22. Пока шарился - размеры файлов не менялись. Времена - тоже. Или на серверах не настроено единое время ... или это разные БД. Где лежат файлы настройки Мускуля и файлы реплики, если таковая есть - не нашел. В обоих логах есть запросы с левыми джойнами к 3 табличкам и с временем выполнения от 6.8 до 29 сек. При этом Мускуль просматривает от 1 до 4 миллионов записей с итогом выдачи от пусто до 5000... из характера запросов - не обнаружил необходимость именно левого соединения... но там похоже или какая-то cms или фреймворк. Возможно левое соединение генерится автоматически. Это уже к автору. Можно предположить, что ПХП-клиент с одного сервера обращается к БД на другой ... или нет? В общем, кто лучше знает free bsd unix, тому и карты. :) Не разобравшись с конфигурацией, смотреть саму БД не вижу смысла. Похоже, что косяк именно промеж серверов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2014, 19:56:02 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
Arhat109Можно предположить, что ПХП-клиент с одного сервера обращается к БД на другой ... или нет? да, на самом деле сейчас происходит именно так, а это плохо? ) p.s.: сервера вроде как стоят рядом, в одном дата-центре ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2014, 20:06:46 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
kayuchkin, ответил письмом. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2014, 20:07:09 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
[quot kayuchkin] По поводу "брать каждый запрос и тюнить": Мы давно и достаточно долго оптимизировали структуру базы и запросы, проверяли что везде используются нужные индексы и т.д. [/quot kayuchkin] Почему-то многие считают, что внезапно в mysql ничего не происходит. Еще как происходит. Время идет - данные накапливаются. Планы запросов изменяются. Индексы перестают использоваться. Буферов перестает хватать. Это нужно делать постоянно. Ну хотя бы при заметных ухудшениях. По-прежнему не видим конфигурацию. Хотя например NUMA, которая включается или выключается в зависимости от размера и способа установки памяти по слотам (ну тут уж точно тут во freebsd облажались. кто тестировать-то будет на разнообразном железе ?), может привести к аномальному замедлению работы простых запросов. Все же CPU: 99.1% user больше намекает на необходимость оптимизации запросов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2014, 21:51:37 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
kayuchkin, срочно расстреляйте вашего верстальщика!!! главная страница почти под 5 мегабайт, при том, что даже статика отдается еле-еле - за гранью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2014, 22:01:14 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
kayuchkinНедавно перенесли базы на отдельный сервер (он у нас пустовал -- такой же конфигурации, в этом же дата-центре, только оперативной памяти вдвое больше). После этого начались проблемы с базой. Очевидно, что проблема где-то в неправильной настройке базы или сервера, а не в неоптимизированных запросах. во первых, вовсе и не очевидно. во вторых ты будешь когда разбирать первый запрос, ты и поймешь, что не так. конфигурации "было" и "стало" сравнивали, надеюсь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2014, 01:17:37 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
интересно, мы содержимое mysql-slow.log увидим или нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2014, 01:20:45 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
kayuchkinArhat109Можно предположить, что ПХП-клиент с одного сервера обращается к БД на другой ... или нет? да, на самом деле сейчас происходит именно так, а это плохо? ) p.s.: сервера вроде как стоят рядом, в одном дата-центре нет, это наоборот хорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2014, 01:21:11 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
кроме того, вы же данные т. н. Бэкапом переносили, наверное? Статистику по таблицам собирали после загрузки данных? индексы все создали? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2014, 01:25:31 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
MasterZivkayuchkinпропущено... да, на самом деле сейчас происходит именно так, а это плохо? ) p.s.: сервера вроде как стоят рядом, в одном дата-центре нет, это наоборот хорошо. но плохо что их вообще разделили. ну, по крайней мере, это есть привнесенное изменение в систему из-за которого она может работать медленее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2014, 02:11:18 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
miksoft, Я его выкачивать не стал, не увидел в нем ничего такого, кроме регулярных запросов с большим временем выполнения, и они все идут с левым джойном к 3 и более таблицам. Главная - разная, вторая всегда users, третья и т.д. - тоже зависят от запроса ... ни в одном нет проверки на IS NULL, как явный признак необходимости left join, и часто стоит WHERE 1=1, из чего делаю вывод, что они собраны "чем-то" (cakePHP - есть такой?) и надо ли там именно левый джойн - не очевидно. Каждый такой тормозной запрос перелопачивает от миллиона записей. Часто результат к возврату - отсутствует. То есть результат выборки - пуст. Как понимаю, именно тут и создаются временные таблички. masterZiv, Вы на сайт ходили? Зачем рекомендовать человеку заведомо неграмотное решение? В каких конкретно случаях разнесение клиента и сервера БД дает прирост производительности? Как часто такое у означенных сайтов? С каких пор передача по локальной петле в рамках одного железа стала хуже передачи по сети, пусть даже гигабитной между двумя компами? Там надо всё возвращать на один комп и заниматься оптимизацией запросов, устраняя левые соединения везде где они не востребованы по задаче клиента. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2014, 07:12:47 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
Arhat109miksoft, Я его выкачивать не стал, не увидел в нем ничего такого, кроме регулярных запросов с большим временем выполнения, и они все идут с левым джойном к 3 и более таблицам. Главная - разная, вторая всегда users, третья и т.д. - тоже зависят от запроса ... ни в одном нет проверки на IS NULL, как явный признак необходимости left join, и часто стоит WHERE 1=1, из чего делаю вывод, что они собраны "чем-то" (cakePHP - есть такой?) и надо ли там именно левый джойн - не очевидно. Каждый такой тормозной запрос перелопачивает от миллиона записей. Часто результат к возврату - отсутствует. То есть результат выборки - пуст. Как понимаю, именно тут и создаются временные таблички.Что-то не догоняю, а зачем такого рода запросам дисковые временные таблицы? Там нет ORDER BY, GROUP BY, подзапросов, VIEW, агрегатных функций и т.п. ? Что с планом? Не надо ли добавить индексов? Не применить ли покрывающие индексы (благо, что памяти для их кэширования достаточно)? Хорошо бы еще порог попадания в slow-log снизить до секунды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2014, 09:59:30 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
miksoft, :) Эт, я забыл черкануть сюда. Конечно же есть любимый групбай... :) В саму базу через клиента я не полез ибо нет смысла. Пока нет. То же самое и с сокращением времени slow log. Там надо сначала собрать всё на один комп, возможно дорастив ему оперативы (комп с сайтом - только 4 гектара), или обосновать и сделать полноценную реплику, потом прочистить запросы от левых джойнов и ненужных групбаев, потом надавать дизайнеру и верстальщику по шеям и разгрузить вес страниц (как Вы верно заметили, а я - упустил) ... итолько потом смотреть чего ишо можно улучшить. :) Автору большую часть этого я отписал, свою консультацию провел ... а уж чего он решит, пусть сам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2014, 12:56:23 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
Arhat109miksoft, Я его выкачивать не стал, не увидел в нем ничего такого, кроме регулярных запросов с большим временем выполнения, и они все идут с левым джойном к 3 и более таблицам. Главная - разная, вторая всегда users, третья и т.д. - тоже зависят от запроса ... ни в одном нет проверки на IS NULL, как явный признак необходимости left join, и часто стоит WHERE 1=1, из чего делаю вывод, что они собраны "чем-то" (cakePHP - есть такой?) и надо ли там именно левый джойн - не очевидно. Каждый такой тормозной запрос перелопачивает от миллиона записей. Часто результат к возврату - отсутствует. То есть результат выборки - пуст. Мужчина, так вот и надо брать ПО ОДНОМУ эти вот запросы, и решать проблемы их производительности. Бери сначала самый долгий. Не, не так. Частый (нужно знать приложение), но долгий. Т.е. если самый долгий -- редкий, его не бери. Бери следующий по длительности, и так далее, пока не найдёшь часто выполняемый. Его оптимизируй (надо понять, в чём проблема и её исправить). И очень вероятно, что "ремонт" одного запроса потянет за собой исправление многих запросов. ПОСЛЕ исправления -- очищаешь slow query log, ждёшь, когда он снова наполнится -- и снова повторяешь операцию (для следующего запроса). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2014, 13:20:29 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
Arhat109Вы на сайт ходили? . Мне твой сайт ни к чему. GUI морда ни о чём не говорит. Arhat109Зачем рекомендовать человеку заведомо неграмотное решение? В каких конкретно случаях разнесение клиента и сервера БД дает прирост производительности? Всегда. Это повышает вычислительные мощности системы. Примерно в 2 раза, если одинаковые серваки. Это не даст прирост только если у вас очень слабая загрузка, тогда производительность останется такой же. Arhat109Как часто такое у означенных сайтов? С каких пор передача по локальной петле в рамках одного железа стала хуже передачи по сети, пусть даже гигабитной между двумя компами? А что, у вас между компами не гигабитная сетка на волокне ? Arhat109Там надо всё возвращать на один комп и заниматься оптимизацией запросов, устраняя левые соединения везде где они не востребованы по задаче клиента. Не, ну, мужчина, как хочешь. Я тебе даю полезные советы, бесплатно, а там уж твоё дело, делать, как будет лучше, или себе же хуже. Вообще, в принципе, когда БД и что-то ещё на одной машине -- производительность достаточно сложно отслеживать. Даже в этом огромный плюс. Когда MySQL(или кто ещё) считает запрос, а тут поступает запрос в appach и он под себя берёт всё CPU вытесняя MySQL нафиг из проца, то тут что можно мониторить ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2014, 13:26:02 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
Arhat109или обосновать и сделать полноценную реплику, Реплика-то как производительности поможет ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2014, 13:29:12 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
MasterZiv, вот это: Всегда. Это повышает вычислительные мощности системы. Примерно в 2 раза, если одинаковые серваки. обоснуйте тупому, желательно с цифирьками. А также вы умолчали про соотношение скоростей передачи данных по внутренней петле в одном компе и гигабитной сетью, пусть даже в случае ровно двух компов, без чего либо ещё в этой сети. Интересно Ваше мнение как специалиста. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2014, 13:37:23 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
автор Примерно в 2 раза, если одинаковые серваки. а пацаны и не знают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2014, 14:31:51 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
Arhat109MasterZiv, вот это: Всегда. Это повышает вычислительные мощности системы. Примерно в 2 раза, если одинаковые серваки. обоснуйте тупому, желательно с цифирьками. Чего тебе обосновывать-то ? У тебя один сервер. В нём скажем 16 гиг памяти и 8 процов. Ты ставишь второй такой же -- суммарно получается 32 гиг памяти и 16 процов. Скорость передачи данных между WEB-сервером и СУБД не должна быть такой уж критичной, потому что от WEB-сервера в СУБД поступают запросы, их объём в видеданных маленький, а обратно из СУБД в WEB-сервер идут только результаты этих запросов, которые также небольшие по объему, если конечно приложение нормально спроектировано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2014, 16:04:24 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
MasterZiv, Да... а пацаны-то и не знают. Пасибки. То есть, ежели я поставлю 100 веб-морд и 100 SQL серваков, то мой сайт будет шустрее ровно ... в 200 раз? Круть. (побежал за железом) Вы так и НЕ ответили: во сколько РАЗ скорость гигабитной подсети промеж двух компов шустрее внутренней петли одного компа... Почто так "игнорите"? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2014, 16:35:54 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
Да... а пацаны-то и не знают. Пасибки. То есть, ежели я поставлю 100 веб-морд и 100 SQL серваков, то мой сайт будет шустрее ровно ... в 200 раз? Круть. (побежал за железом) при правильной архитектуре - да, почти в 200 раз. по сравнению с одним таким компом и при бесконечно растущей нагрузке, естественно. Вы так и НЕ ответили: во сколько РАЗ скорость гигабитной подсети промеж двух компов шустрее внутренней петли одного компа... я тебе ответил, что скорость сети тебе особенно не важна. потому что там трафик не такой и большой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2014, 21:00:47 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
MasterZiv, Нет, так и НЕ ответили, а только виляете. Ибо хорошо знаете, что скорость гигабитной сети никак не в состоянии превысить порог в 42 мегабайта в сек. (1000Мбит / 12бит / 2 - окно Ethernet), что даже ниже скорости средненького винчестера под виндой (60-80), а скорость внутренней петли измеряется сотнями метров, если не гектарами в ту же самую секунду. То есть это самое медленное звено во всей последовательной(!) цепи обработки HTML-запроса (PHP_клиент - сеть - мускуль - ФС - мускуль - сеть - PHP_клиент). А теперь следим за пальцами: был один сервер и он ... справлялся. Стало 2 и начались проблемы, что и явилось причиной появления автора тут... вы же пишете что его решение есть "хорошо". Есть, и хорошо, но не для задач клиента. Поэтому и спрашивал, в каких случаях это решение есть хорошо. Ни одного примера от Вас - не последовало, тока теория высосанная из пальца. А жаль. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2014, 21:35:21 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
авторпри правильной архитектуре - да, почти в 200 раз. а расскажите ка про эти секретные приборы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2014, 01:28:50 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
авторНет, так и НЕ ответили, а только виляете. Ибо хорошо знаете, что скорость гигабитной сети никак не в состоянии превысить порог в 42 мегабайта в сек. (1000Мбит / 12бит / 2 - окно Ethernet), что даже ниже скорости средненького винчестера под виндой (60-80), а скорость внутренней петли измеряется сотнями метров, если не гектарами в ту же самую секунду. То есть это самое медленное звено во всей последовательной(!) цепи обработки HTML-запроса (PHP_клиент - сеть - мускуль - ФС - мускуль - сеть - PHP_клиент). Мужчина, ещё уже наверное 5-ый раз -- нет там между сервером приложений (WEB) и СУБД какого-то огромного траффика. Не должно его просто быть в такой архитектуре. Он там мизерный. авторА теперь следим за пальцами: был один сервер и он ... справлялся. Стало 2 и начались проблемы, что и явилось причиной появления автора тут... вы же пишете что его решение есть "хорошо". Есть, и хорошо, но не для задач клиента. Для клиента было бы хорошо, если бы он хоть один запрос опубликовал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2014, 10:33:22 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
ScareCrowавторпри правильной архитектуре - да, почти в 200 раз. а расскажите ка про эти секретные приборы? Чё расказать та ? Sharding, shared nothing cluster поищи, и почитай. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2014, 10:34:21 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
MasterZiv, Ок, вьюноша. А какой траффик будем считать "огромным"? Эта цепочка - строго последовательна. Скажем типовые значения времен: таких цепочек на запрос в среднем около десятка: а) PHP-клиент(1) - 3мсек б) запрос по сети в Мускуль - 0,2мсек в) Мускуль (парсинг запроса и подготовка) - 10мсек г) Мускуль (выполнение запроса, типовое значение) если из кеша 10мсек. д) возврат по сети 100 записей по 4кб каждая (часто ибо текстом) = 0,4Мб / 42Мб (гигабитка) = 10 мсек Итого на цепочку = 3+0,2+10+10+10 = 33,2 мсек. При этом доля времени сетевого интерфейса ... 10.2/33.2 = 30,7% ... да и правда, не огромное время , так мелочь. Вот этой трети в данном случае и НЕ ХВАТИЛО. Не советуйте того, в чем не разбираетесь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2014, 11:49:29 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
автор42 мегабайта в сек. (1000Мбит / 12бит / 2 - окно Ethernet)Что за странный расчет? А то, что я своими глазами вижу скорость копирования файлов с 80-90 Мбайт/с (да еще плюс накладные расходы на самбу и т.п.) - мираж? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2014, 12:28:52 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
miksoft, :) Согласно стандарту Ethernet-1000TX, да и всего Ethernet. Передача должна иметь окно молчания в 50% - то бишь "половина". Передача идет в 12 бит на байт. А где и чем смотрите и что у вас за оборудование? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2014, 13:23:09 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
Arhat109, Впрочем, пусть даже в датацентрах стоит сетка с 100 метров в сек. Скорость хорошего винчестера. Ну получится для кешированных запросов 15% потеря времени по сравнению с внутренней петлей одной машины... не принципиально. Всё равно это самое слабое звено. Да даже на одном компе! Время получения результата - впрямую и сильно зависит от ... количества возвращаемых данных. Ибо внутренняя петля - тоже далеко не идеальное решение. То есть, рекомендовать посадить клиента на один комп, а СУБД на другой - это тупо неграмотно. Кстати, в озвученных словах про шардинг, таки применяются несколько иные подходы... и при других обстоятельствах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2014, 13:30:30 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
Arhat109Передача должна иметь окно молчания в 50% - то бишь "половина". Передача идет в 12 бит на байт.Это если и было когда-то, то точно не в последние лет 20... Arhat109А где и чем смотрите и что у вас за оборудование?Да тупо файл с сервака копирую. Arhat109Ибо внутренняя петля - тоже далеко не идеальное решение.Дык вроде сокеты используют, когда все на одном компе. Они еще быстрее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2014, 14:41:16 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
В целом предлагаю бессмысленные бодания насчет скорости завершить, и так уже наоффтопили. По задаче топикстартера у кого-то какие-то дополнительные сведения, замечания, вопросы есть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2014, 14:42:46 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
Arhat109А какой траффик будем считать "огромным"? мегобайты ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2014, 15:06:46 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
miksoftВ целом предлагаю бессмысленные бодания насчет скорости завершить, и так уже наоффтопили. По задаче топикстартера у кого-то какие-то дополнительные сведения, замечания, вопросы есть? Так он не колется. Запросы не даёт. Так что -- нет, не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2014, 15:08:58 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
еще один кусок офтопика... а) PHP-клиент(1) - 3мсек б) запрос по сети в Мускуль - 0,2мсек в) Мускуль (парсинг запроса и подготовка) - 10мсек г) Мускуль (выполнение запроса, типовое значение) если из кеша 10мсек. д) возврат по сети 100 записей по 4кб каждая (часто ибо текстом) = 0,4Мб / 42Мб (гигабитка) = 10 мсек это замечательный пример того, как не надо делать приложения. пункты б-д вообще не должны существовать, если это предопределенные данные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2014, 19:46:14 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
MasterZiv, Не знаю, кто и что там и кому "должен" или наоборот. Я привел типовой цикл работы веб приложений. Их таких 99.99% или около. Согласен, давайте прекратим оффтоп. Объявится автор - можем спросить "чего оно сейчас", но мне кажется он уже на каникулах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2014, 20:40:27 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
Ну вот. Автор отписался, что проблема найдена и решена. Сервер ДДОСился ... кроном. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2014, 06:39:21 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
Arhat109Ну вот. Автор отписался, что проблема найдена и решена. Сервер ДДОСился ... кроном. :) по крону бэкап делали? почитал тут ваши разборки, так замечание - 1. использование localhost при коннекте к mysql дело нехорошее, что вы всё время про эту петлю ;) 2. К автору с его 300-400 пользователей в день конечно не относится (ИМХО исользуемое ими оборудование - деньги на ветер, хотя возможно это дешевле чем привести приложение в порядок), но самое узкое место всё-же файловая система ( что на сервере БД что на сервере приложения ) т.к. 60 Мб/с вы на ней не получите ( если обычные не SSD диски), даже с хорошим кэширующим рэйдом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2014, 08:18:18 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
Arhat109, тогда, наверное, не ДДОСился, а ДОСился? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2014, 08:22:15 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
tanglir, Да фиг его знает как верно... :) Там в кроне как раз и сидел тот генератор запросов, который с левыми джойнами и группировками, как понимаю. Просто "до" разделения он гонялся скажем так "изредка", а при переносе, видимо его перенастроили "не так" и он начал исполняться очень часто, чем и подвесил всю систему, при столь низкой нагрузке. Это со слов автора. Тем не менее, вопрос оптимизации запросов, ИМХО, там стоит явно. По-поводу петли - безусловно плохо. Но, сколько раз поднимал Мускуль, столько раз видел её траблы при настройках по умолчанию. Большинство также часто гоняет Мускуль в типовом конфиге "не заморачиваясь". Так что вопрос - актуален. Насчет HDD - категорически не согласен. Нормальные серверные, а не бытовые винты, дают скорость обмена в районе 120-150 Мб/сек. А в рейде - вполне реально получать до 250Мб/сек. и более. Сам делал эксперимент с рейд-0 о 4-х винтах (больше не было) и нормальном raid-контроллере... получить скорость под 400 метров в сек - вполне реально. Другой вопрос надежности такой системы, но это - таки другой вопрос. Но, опять же. Если это slave реплика только на чтение - то и пофиг. :) Типовые решения - далеко не всегда "Айс"... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2014, 09:21:43 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
Arhat109tanglir, Да фиг его знает как верно... :) Там в кроне как раз и сидел тот генератор запросов, который с левыми джойнами и группировками, как понимаю. Просто "до" разделения он гонялся скажем так "изредка", а при переносе, видимо его перенастроили "не так" и он начал исполняться очень часто, чем и подвесил всю систему, при столь низкой нагрузке. Это со слов автора. Тем не менее, вопрос оптимизации запросов, ИМХО, там стоит явно. По-поводу петли - безусловно плохо. Но, сколько раз поднимал Мускуль, столько раз видел её траблы при настройках по умолчанию. Большинство также часто гоняет Мускуль в типовом конфиге "не заморачиваясь". Так что вопрос - актуален. Насчет HDD - категорически не согласен. Нормальные серверные, а не бытовые винты, дают скорость обмена в районе 120-150 Мб/сек. А в рейде - вполне реально получать до 250Мб/сек. и более. Сам делал эксперимент с рейд-0 о 4-х винтах (больше не было) и нормальном raid-контроллере... получить скорость под 400 метров в сек - вполне реально. Другой вопрос надежности такой системы, но это - таки другой вопрос. Но, опять же. Если это slave реплика только на чтение - то и пофиг. :) Типовые решения - далеко не всегда "Айс"... диски: вы мерили не случайный доступ, и не "во много потоков"... mysql после 5.4 или даже раньше ( в том числе драйвера) при написании localhost используют socket, в документации вроде так было :) так сказать подумали за массовых пользователей ( ИМХО не нужно так делать ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2014, 09:42:15 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
NikolayV81, Я разный доступ мерял... :) Насчет Мускуля 5.4 - ничего сказать не могу. Последний, который пользую - 5.1. как самый шустрый. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2014, 10:36:52 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
Arhat109NikolayV81, Я разный доступ мерял... :) Насчет Мускуля 5.4 - ничего сказать не могу. Последний, который пользую - 5.1. как самый шустрый. :) с fork-ами сравнивали, или у вас myisam? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2014, 10:46:20 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
NikolayV81, Иннодебил, и был xtraDb в одном проекте. MyISAM - не СУБД ни разу. Уже обсуждалось, холиварить незачем. В смысле отвечать не буду. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2014, 11:10:49 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
NikolayV81 mysql после 5.4 или даже раньше ( в том числе драйвера) при написании localhost используют socket, в документации вроде так было :) так сказать подумали за массовых пользователей ( ИМХО не нужно так делать ) Ну так прежде чем писать уточните это в документации. На не существовавшую версию 5.4. Сокеты - это тип интерфейса для межпроцессной коммуникации. В unix mysql сокеты использует обязательно, но разных типов. Cокеты типа unix, которые использует mysql при указании специального имени "localhost" несколько проще в реализации и поэтому немного быстрее. Ничего там не поменялось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2014, 14:41:22 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
netwindNikolayV81 mysql после 5.4 или даже раньше ( в том числе драйвера) при написании localhost используют socket, в документации вроде так было :) так сказать подумали за массовых пользователей ( ИМХО не нужно так делать ) Ну так прежде чем писать уточните это в документации. На не существовавшую версию 5.4. Сокеты - это тип интерфейса для межпроцессной коммуникации. В unix mysql сокеты использует обязательно, но разных типов. Cокеты типа unix, которые использует mysql при указании специального имени "localhost" несколько проще в реализации и поэтому немного быстрее. Ничего там не поменялось. С версиями не угадал ;) про немного, сложно сказать... http://osnet.cs.binghamton.edu/publications/TR-20070820.pdf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2014, 17:18:17 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
NikolayV81 С версиями не угадал ;) а с чем угадали? очевидно, что одни способы обмена лучше чем другие, но на фоне затрат на собственно обработку запросов, это теряется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2014, 17:49:19 |
|
||
|
Срочно нужна помощь с оптимизацией INNODB
|
|||
|---|---|---|---|
|
#18+
netwindNikolayV81С версиями не угадал ;) а с чем угадали? очевидно, что одни способы обмена лучше чем другие, но на фоне затрат на собственно обработку запросов, это теряется. Тут по ветке выше... В принципе по сравнению со временем существования мира, любой отрезок времени доступный человеку не является существенным :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2014, 17:55:10 |
|
||
|
|

start [/forum/topic.php?all=1&fid=47&tid=1833754]: |
0ms |
get settings: |
7ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
43ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 229ms |
| total: | 353ms |

| 0 / 0 |
