огого

Даже через Propel/Doctrine?

хотя какая разница через что

@chebotarevp Спасибо

Вопрос в том, насколько. Теоретически, думаю что не особо медленнее.

субд видимо когда обходит строки то создает какие-нибудь легковесные структуры-указатели на данные, которые попадут в результат.

Смотрю потихоньку в сторону хайлоад, вот хочу к тому моменту как с ним работать придется, знать хоть какието вещи по этому, а не учить в процессе

Мужики здарова. Подскажите пожалуйста с выборкой данных. Есть к примеру таблица с колонками (a,b,c, ..., x, z) Мне по факту нужны значения не из всех колонок, а только к примеру из колонок (a, b, h, z) Я постоянно беру все значения (Propel) и пользуюсь нужным. на быстродействие БД (именно БД а не серверного кода php) это как то влияет? Мне кажется что если запросить все поля, то это отрабатывает бастрее, нежели если я перечислю нужные. Скажите я ошибаюсь?

во-первых, если выбирать все колонки, а не только нужные, данных по сети нужно передавать больше. во-вторых, если серверу объяснить, что на самом деле нужно, а не выбирать всё подряд, сервер может лучше оптимизировать выполнение запроса. Например, если все нужные колонки присутствуют в индексе, сервер может делать index-only scan и не тратить время на чтение самих строк

но производительность — не единственная причина, почему select * это зло. в сети целые статьи на эту тему написаны

@alexey_kopytov Propel select * не делает, а перечисляет все поля

@alexey_kopytov Спасибо за то что "разжевал"

Всем привет! Господа, есть такой вопрос: В наличии имеется MySQL 5.7.19, в ней 5-6 схем, почти всё на InnoDB. С базой работает сайт и интеграция с ERP. Нагрузка примерно: чтение 20-30Kq/s, запись 7-10Kq/s Бэкап осуществляется средствами Percona 1 раз в сутки. Суть проблемы в следующем: После запуска демона, буфферы InnoDB и прочие потихоньку заполняются и примерно за сутки-двое MySQL выходит в рабочий режим. Но проблема в том, что после этого оперативка продолжает куда-то уходить. Сперва думал, что это бага MySQL, связанная с утечкой памяти, но её исправили в версии 5.7.16, если я ничего не путаю. Собственно вопрос в следующем: Куда копать, чтобы найти кнопку "сделать всё классно", или хотя бы как найти способ узнать, куда уходит память. Есть весьма высокая вероятность того, что проблема кроется в "плохих" запросах, но вот как отследить, что именно выжирает память? Так же слышал, что InnoDB_buffer_pool_size может вырасти больше заявленного в конфиге значения, но по факту ни разу не видел, что бы значение show status like 'InnoDB_buffer_pool_bytes_data' было больше заданного в конфиге. MyISAM почти не используется. Подскажите, куда копать? Мне нужно найти кнопку "сделать всё классно" или указать разработчикам, в чём они не правы :) А то рестартовать БД каждую неделю - такое себе. Ещё из наблюдений: - часть данных БД, около 15 ГБ, постоянно попадает в swap (OS Ubuntu Server 16.04) - резко возросло использование памяти за одну ночь (+10ГБ), кто-нибудь сталкивался, чтобы percona innobackupex заставляла MySQL выжирать память и не высвобождать её?

Всем привет! Господа, есть такой вопрос: В наличии имеется MySQL 5.7.19, в ней 5-6 схем, почти всё на InnoDB. С базой работает сайт и интеграция с ERP. Нагрузка примерно: чтение 20-30Kq/s, запись 7-10Kq/s Бэкап осуществляется средствами Percona 1 раз в сутки. Суть проблемы в следующем: После запуска демона, буфферы InnoDB и прочие потихоньку заполняются и примерно за сутки-двое MySQL выходит в рабочий режим. Но проблема в том, что после этого оперативка продолжает куда-то уходить. Сперва думал, что это бага MySQL, связанная с утечкой памяти, но её исправили в версии 5.7.16, если я ничего не путаю. Собственно вопрос в следующем: Куда копать, чтобы найти кнопку "сделать всё классно", или хотя бы как найти способ узнать, куда уходит память. Есть весьма высокая вероятность того, что проблема кроется в "плохих" запросах, но вот как отследить, что именно выжирает память? Так же слышал, что InnoDB_buffer_pool_size может вырасти больше заявленного в конфиге значения, но по факту ни разу не видел, что бы значение show status like 'InnoDB_buffer_pool_bytes_data' было больше заданного в конфиге. MyISAM почти не используется. Подскажите, куда копать? Мне нужно найти кнопку "сделать всё классно" или указать разработчикам, в чём они не правы :) А то рестартовать БД каждую неделю - такое себе. Ещё из наблюдений: - часть данных БД, около 15 ГБ, постоянно попадает в swap (OS Ubuntu Server 16.04) - резко возросло использование памяти за одну ночь (+10ГБ), кто-нибудь сталкивался, чтобы percona innobackupex заставляла MySQL выжирать память и не высвобождать её?

а сколько памяти на машине? я вижу 128 GB buffer pool + 300 max_connections * (per connection buffer) = 184 GB

250

а какой vm.swappiness установлен?

и какой innodb_flush_method используется?

но нет, xtrabackup не может заставить сервер использовать больше памяти. оно на уровне файлов всё копирует, и с сервером общается только для нужных ему блокировок

а ещё, это NUMA машина? если да, используется ли innodb_numa_interleave?

а какой vm.swappiness установлен?

10, но сейчас использовано 150Гб и в swap уже 12ГБ.

подозреваю, что дело в numa

и какой innodb_flush_method используется?

O_DSYNC

ой. а почему не O_DIRECT?

там же наверное page cache ещё раздутый из-за этого

ой. а почему не O_DIRECT?

ruhighload пишет, что его стоит использовать в случае, если не настроен бэкап БД, но я почитаю еще. В общем то мне это сокровище досталось как есть, не я на страивал. Сейчас разбираюсь что к чему.

очень рекомендую O_DIRECT

там же наверное page cache ещё раздутый из-за этого

А где посмотреть?

А где посмотреть?

free?

я бы ещё посмотрел на numastat -m и на numastat -m -p $(pidof mysqld)

ruhighload пишет, что его стоит использовать в случае, если не настроен бэкап БД, но я почитаю еще. В общем то мне это сокровище досталось как есть, не я на страивал. Сейчас разбираюсь что к чему.

а что за ruhighload кстати?

а ещё, это NUMA машина? если да, используется ли innodb_numa_interleave?

Не знаю что это, пойду почитаю. Но параметр стоит в OFF

а что за ruhighload кстати?

https://ruhighload.com/post/Выбор+innodb_flush_method+между+O_DSYNC+и+O_DIRECT

Не знаю что это, пойду почитаю. Но параметр стоит в OFF

numactl -H сразу всё покажет

мда, у меня вообще на слово highload аллергия. но этот ruhighload какой-то совсем сомнительный источник

Этот метод использует 4 операции записи на диск на каждый вызов. Лучше использовать когда для БД не настроен бэкап, и нет возможности быстро переключиться на резервную копию. хехе

или даже бугага

Не знаю что это, пойду почитаю. Но параметр стоит в OFF

вот тут лучше начинать читать: https://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/

только не забывать, что это было написано давно и те самопальные опции, которые он тогда сделал, уже есть в MySQL 5.7, но называются по-другому

но саму проблему он хорошо описал

вот тут лучше начинать читать: https://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/

Хорошо, спасибо.

free?

А, я думал речь о значениях внутри MySQL

нет, page cache — это же ядерная вещь. когда innodb_flush_method != O_DIRECT, будет использоваться 2 кэша: innodb_buffer_pool и системный page cache. и это плохо

если коротко и нужна кнопка "сделать всё классно", то вот они: innodb_flush_method=O_DIRECT innodb_numa_interleave=1

если коротко и нужна кнопка "сделать всё классно", то вот они: innodb_flush_method=O_DIRECT innodb_numa_interleave=1

Ага, спасибо, я уже прочитал "по диагонали". Щас более подробно читаю.

если коротко и нужна кнопка "сделать всё классно", то вот они: innodb_flush_method=O_DIRECT innodb_numa_interleave=1

На сколько мне известно системный кэш автоматически высвобождается, когда требуется память для работы приложения. А тут дело в том, что растёт использование памяти именно процессами MySQL. По этому сперва хочу прочитать, как мне это поможет. Оно явно поможет, потому что замечаются тупняки, когда используемая MySQL память переваливает за 210ГБ. Но поможет ли это избежать того факта, что на столько вырастает количество используемой памяти? И перестанет ли она расти до того как oom начнёт приносить детей в жертву хД

это в старые добрые времена всё было просто. нужна память — освобождается системный кэш

сейчас всё сложно, и полностью на 100% как это работает, не понимает по-моему никто. всё сводится к шаманским пляскам вокруг vm.* настроек. но swappiness нужно в 1 (не в 0!) устанавливать, в этом все сходятся

если коротко и нужна кнопка "сделать всё классно", то вот они: innodb_flush_method=O_DIRECT innodb_numa_interleave=1

Спасибо за ответ, тоже есть аналогичная проблема и задача в списке на поиск решения. Я про NUMA

сейчас всё сложно, и полностью на 100% как это работает, не понимает по-моему никто. всё сводится к шаманским пляскам вокруг vm.* настроек. но swappiness нужно в 1 (не в 0!) устанавливать, в этом все сходятся

согласен

SELECT a.id, b.id FROM (SELECT …) AS a, (SELECT …) AS b Почему вложенные селекты по отдельности выполняются очень быстро, а запрос выше выполняется очень долго?

Разобрался... потому что итоговая таблица содержит овермного записей (кол-во записей в первом вложенном запросе умноженное на кол-во записей во втором вложенном запросе)... Буду думать как оптимизировать это дело

@alexey_kopytov Спасибо за то что "разжевал"

Индекс на все свои поля поставь, которые тянешь. Но заведомо знай, что будет жрать место, ибо индекс - копия твоих полей

не надо индекс на все поля

если коротко и нужна кнопка "сделать всё классно", то вот они: innodb_flush_method=O_DIRECT innodb_numa_interleave=1

Тут коллеги утверждают, что у O_DIRECT обязательное требование - наличие батарейки на раид контроллере, как-то сомнительно на мой взгляд. Я так полагаю, при O_DSYNC требование абсолютно такое же должно быть.

Тут коллеги утверждают, что у O_DIRECT обязательное требование - наличие батарейки на раид контроллере, как-то сомнительно на мой взгляд. Я так полагаю, при O_DSYNC требование абсолютно такое же должно быть.

что за ерунда. за сохранность данных отвечает транзакционный журнал и fsync() на файлы данных. O_DIRECT не отменяет ни того, ни другого. Он просто исключает page cache из уравнения. в смысле, данные идут сразу на устройство (не важно, есть у него кэш или нет), а не в page cache. но за фактический сброс отвечает fsync

Привет! У меня есть задача поместить в один столбец несколько текстовых значений. Как сделать такое? Может есть вариант это сделать не в рамках одного столбца?

Привет! У меня есть задача поместить в один столбец несколько текстовых значений. Как сделать такое? Может есть вариант это сделать не в рамках одного столбца?

Может это нужно было бы сделать с помощью яп. Например обрабатывать запрос одного столбца пока не попадается определенный знак. Но я реализую это через добавления по одной букве к переменной. Мне кажется, что будет слишком сильно тормозить.

разделитель между словами и на яп распарсить. ну или json

разделитель между словами и на яп распарсить. ну или json

Я тоже уже пришел к этому. Это не будет медлить слишком сильно? Там отсилы по 3-5 слов где-то в 7-8 символов. Костыль есть костыль, можно ли без него напрямую это с MySQL сделать?

Я тоже уже пришел к этому. Это не будет медлить слишком сильно? Там отсилы по 3-5 слов где-то в 7-8 символов. Костыль есть костыль, можно ли без него напрямую это с MySQL сделать?

Но проверки буду частыми.

Я тоже уже пришел к этому. Это не будет медлить слишком сильно? Там отсилы по 3-5 слов где-то в 7-8 символов. Костыль есть костыль, можно ли без него напрямую это с MySQL сделать?

По вопросам производительности - жди ответа местных гуру. Но я не думаю что это будет тормозить работу.

По вопросам производительности - жди ответа местных гуру. Но я не думаю что это будет тормозить работу.

Хорошо. Спасибо за помощь.

Текстовые значения как отличать будешь? по счету?

в запросе поиск по этим значениям планируется?

Добрый день! Столкнулся с проблемой не могу в увеличть значение thread_cache_size > 16384. И не могу понять почему, может кто подскажет? Система: Centos 7.3 x64, Percona 5.7.20.

как увеличиваешь? как проверяешь значение? mysql после измений рестартил?

Добрый день! Столкнулся с проблемой не могу в увеличть значение thread_cache_size > 16384. И не могу понять почему, может кто подскажет? Система: Centos 7.3 x64, Percona 5.7.20.

можно было бы посмотреть в документацию. я лично всегда так делаю. там написано, что 16384 — максимальное значений для thread_cache_size. но даже если не так, в логе об этом тоже напишут при попытке установить большее значение

Увеличиваю в my.cnf. mysqladmin -u root -p extended-status | grep Threads Да, скуль перезапускаю.

и я на 100% уверен, что вам не нужно устанавливать это в значение больше 16384. вы скорее всего решаете какую-то другую проблему не теми средствами

Да, при увеличении значения больше в 16384, в логах скуля есть предупреждение.

это хрень какая-то, извините. что за софтина считает "эффективность thread cache", деля Threads/created на connections?

Рекомендации mysqltuner. Variables to adjust: join_buffer_size (> 256.0M, or always use indexes with joins) thread_cache_size (> 16384) P.s. Я то понимаю что возможно виной тому код шаблона который мы изспользуем под магазин.

| Threads_cached | 0 | | Threads_connected | 2 | | Threads_created | 16752 | | Threads_running | 2

а show status like 'Max_used_connections'?

и show variables like `max_connections'?

Max_used_connections | 7 max_connections | 92

кусок конфигурации скуля

хм, а что показывает show variables like 'thread_cache_size';?

thread_cache_size | 16384

а, ну да. thread_handling = pool-of-threads. уберите это, вам не нужен thread pool при Max_used_connections=7

из-за тред пула не работает thread_cache_size. и mysqltuner это по идее должен учитывать (я смотрю в код), но у вас наверное старая версия какая-то

да и thread_cache_size вам не нужно трогать. дефолтных настроек хватит с головой

MySQLTuner 1.7.4 Попробую

вот в текущей версии есть специальная проверка на pool-of-threads: https://github.com/major/MySQLTuner-perl/blob/master/mysqltuner.pl#L3011

если совсем коротко, проблемы нет. но mysqltuner поднимает шухер, потому что старая версия не в курсе про перконовский thread pool

хм....спасибо. Изменения внес. Проверить сейчас нет возможности. Отпишусь.

на месте автора mysqltuner, я бы все эти проверки на thread cache вообще повыкидывал нафиг

это всё было актуально лет 15-20 назад. сейчас создание треда — это очень дешёвая операция и разница между закешированным и незакешированным тредом конечно есть, но в реальности составляет миллисекунды

зачем вот этим всем ковырять пользователям моск — не понимаю

На личном тестовом сервере внес изменения, все предупреждениея MySQLTuner и Битрикс пропали. Время покажет конечно. Спасибо! Я уже месяц бился и никак вникнуть не могу в чем соль.

после перехода на Percona почитал https://www.percona.com/blog/2014/01/23/percona-server-improve-scalability-percona-thread-pool/

Подумал, что неплохо бы попробовать. И не подумал что потом это выльется в....

это нужно, когда соединений тысячи

мы с автором той статьи вдвоём и работали над перконовским тредпулом. я код писал, а он гонял бенчмарки и по результатам статью написал