@dba_ru

Страница 390 из 718
 
Олег
20.01.2018
23:54:43
база целиком влезает в выделенный буфер пул, с диска ничего не читается

 
и ещё смущает, что очень много тычется во futex(): % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 86.38 0.438388 278 1578 661 futex 13.62 0.069123 148 467 sched_yield 0.00 0.000000 0 2 poll 0.00 0.000000 0 6 sendto 0.00 0.000000 0 20 2 recvfrom ------ ----------- ----------- --------- --------- ---------------- 100.00 0.507511 2073 663 total

 
может кто что дельное подсказать?

 
Alexey
21.01.2018
05:03:12
может кто что дельное подсказать?
в блокировки на Adaptive Hash Index всё упирается. покажи вывод от такого: pager grep 'Hash table size' show engine innodb status;

Google
 
Azat
21.01.2018
09:03:16
а не проще скопипастить его ругань чем расказывать своими словами?
сейчас не на работе, завтра отправлю

 
Олег
21.01.2018
18:12:35
в блокировки на Adaptive Hash Index всё упирается. покажи вывод от такого: pager grep 'Hash table size' show engine innodb status;
Hash table size 34679, node heap has 0 buffer(s) Hash table size 34679, node heap has 1 buffer(s) Hash table size 34679, node heap has 0 buffer(s) Hash table size 34679, node heap has 0 buffer(s) Hash table size 34679, node heap has 1 buffer(s) Hash table size 34679, node heap has 428 buffer(s) Hash table size 34679, node heap has 0 buffer(s) Hash table size 34679, node heap has 0 buffer(s)

 
Hash table size 1182691, node heap has 0 buffer(s) Hash table size 1182691, node heap has 0 buffer(s) Hash table size 1182691, node heap has 0 buffer(s) Hash table size 1182691, node heap has 0 buffer(s) Hash table size 1182691, node heap has 1 buffer(s) Hash table size 1182691, node heap has 1853 buffer(s) Hash table size 1182691, node heap has 0 buffer(s) Hash table size 1182691, node heap has 0 buffer(s)

 
Alexey
21.01.2018
19:57:02
Hash table size 1182691, node heap has 0 buffer(s) Hash table size 1182691, node heap has 0 buffer(s) Hash table size 1182691, node heap has 0 buffer(s) Hash table size 1182691, node heap has 0 buffer(s) Hash table size 1182691, node heap has 1 buffer(s) Hash table size 1182691, node heap has 1853 buffer(s) Hash table size 1182691, node heap has 0 buffer(s) Hash table size 1182691, node heap has 0 buffer(s)
Это https://bugs.mysql.com/bug.php?id=81814

 
Суть в том, что innodb использует плохую хеш функцию, из-за чего все записи попадают в один hash bucket. А параллельные запросы толкутся вокруг лока на него

 
Можно установить innodb_adaptive_hash_index_parts=11. Полегчает, проверено на себе

 
Можно вообще отключить AHI. Чтение просядет процентов на 5, но зато такие всплески latency тоже исчезнут

 
А можно ещё мой патчик приложить. Там в баге есть

 
Олег
21.01.2018
20:05:18
при 11: Hash table size 772757, node heap has 1 buffer(s) Hash table size 772757, node heap has 0 buffer(s) Hash table size 772757, node heap has 0 buffer(s) Hash table size 772757, node heap has 0 buffer(s) Hash table size 772757, node heap has 0 buffer(s) Hash table size 772757, node heap has 0 buffer(s) Hash table size 772757, node heap has 0 buffer(s) Hash table size 772757, node heap has 0 buffer(s) Hash table size 772757, node heap has 1844 buffer(s) Hash table size 772757, node heap has 0 buffer(s) Hash table size 772757, node heap has 0 buffer(s)

 
:)

 
даже простые числа пробовал - не, всё очень плохо

 
почему они эту багу до сих пор не пофиксили?

 
я пытался ещё отключить AHI, но тогда процы в потолок

Google
 
Alexey
21.01.2018
20:07:53
От ahi выигрыш процентов 5, ну максимум 10. Процы в потолок - это скорее следующий квест

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

 
Но вот у меня схема вопросы вызывает. Изменив индекс можно вот эти селекты свести к index-only scan. И тогда ahi станет не нужен

 
Олег
21.01.2018
20:19:42
схема мне, так сказать, по наследству пришла. просто дали проект и вот я здесь

 
спасибо, кстати

 
нашёл почему проц в потолок

 
| Warning | 1739 | Cannot use ref access on index 'INDX_JS_STR' due to type or collation conversion on field 'SEARCH_STR' | Warning | 1739 | Cannot use range access on index 'JS_SEARCH' due to type or collation conversion on field 'SEARCH_STR'

 
в одном из параметров было число. без кавычек оно передавалось как int, поставил одинарные кавычки - стало строкой и запросы залетали

 
в пыхе в параметре в подобие ORM прилетал тип int вместо string и вуаля

 
Alexey
21.01.2018
20:41:53
?

 
Ilia
22.01.2018
05:25:35
привет, полуночники я недавно заходил сюда с вопросом про тупящий mysql, который занят непойми чем. тогда остановились на выключении кеша. не помогло
А я тебе не говорил, что поможет. И никто не говорил. Говорили, что надо его вырубить..

 
mysql> SHOW CREATE TABLE JSON_STORE\G *************************** 1. row *************************** Table: JSON_STORE Create Table: CREATE TABLE `JSON_STORE` ( `ID` int(11) NOT NULL AUTO_INCREMENT, `TYPE` int(3) DEFAULT NULL COMMENT 'тип 1 - поиск, 2 - одтельный продукт', `SEARCH_STR` varchar(255) DEFAULT NULL COMMENT 'Строка поиска\n', `JSON_RESULT` longblob, `PARAMS` varchar(255) DEFAULT NULL COMMENT 'Дополнительные параметры (номер страницы для поисковый запросов, и прочее)', `LAST_UPDATE` datetime DEFAULT NULL, PRIMARY KEY (`ID`), KEY `JS_SEARCH` (`TYPE`,`SEARCH_STR`,`PARAMS`), KEY `INDX_JS_TYPE` (`TYPE`), KEY `INDX_JS_STR` (`SEARCH_STR`), KEY `INDX_JS_PARAM` (`PARAMS`) ) ENGINE=InnoDB AUTO_INCREMENT=1492685 DEFAULT CHARSET=utf8
У тебя есть лишние индексы...

 
Олег
22.01.2018
05:33:48
А я тебе не говорил, что поможет. И никто не говорил. Говорили, что надо его вырубить..
А я не говорил, что совет говно, а вы тут все *** :)

 
Ilia
22.01.2018
05:35:06
и ещё смущает, что очень много тычется во futex(): % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 86.38 0.438388 278 1578 661 futex 13.62 0.069123 148 467 sched_yield 0.00 0.000000 0 2 poll 0.00 0.000000 0 6 sendto 0.00 0.000000 0 20 2 recvfrom ------ ----------- ----------- --------- --------- ---------------- 100.00 0.507511 2073 663 total
Блин 20 ядер это в принципе много, там по любому будут затыки в общие ресурсы... Что ж ты хочешь?

 
Суть в том, что innodb использует плохую хеш функцию, из-за чего все записи попадают в один hash bucket. А параллельные запросы толкутся вокруг лока на него
Ну идеальных хэш функций не бывает в принципе, это не баг. Лучше или хуже но конфликты в хэшах всегда есть и будут.

 
я пытался ещё отключить AHI, но тогда процы в потолок
Так это хорошо по большей части!

 
А я не говорил, что совет говно, а вы тут все *** :)
Но ожидал, что он поможет. В итоге ты вместо поиска банального type mismatch чуть ли не искал баги в ядре...

 
Но ожидал, что он поможет. В итоге ты вместо поиска банального type mismatch чуть ли не искал баги в ядре...
А план этого запроса я так понял ты даже не изучал.

 
Azat
22.01.2018
05:46:18
@Sharptop, @AlexCAD спасибо разобрался, оказывается не было гранта на create session, поэтому так странно себя вел

 
Олег
22.01.2018
05:50:21
А план этого запроса я так понял ты даже не изучал.
Неправильно понял, изучал

Google
 
Ilia
22.01.2018
05:51:13
Тогда классно

 
Олег
22.01.2018
05:51:18
Но ожидал, что он поможет. В итоге ты вместо поиска банального type mismatch чуть ли не искал баги в ядре...
Type mismatch вылез фактически после отключения ahi, до этого он не беспокоил

 
Alexey
22.01.2018
05:51:36
Ну идеальных хэш функций не бывает в принципе, это не баг. Лучше или хуже но конфликты в хэшах всегда есть и будут.
я не говорил, что бывают идеальные хэш функции. но хэш функция, которая возрастающие подряд числа мапит в одно число — плохая, без вариантов. это тот случай, когда отсутствие хэш функции лучше, тем такая. что я и предлагаю в своём пачте для бага

 
но тот патч для этого конкретного случая бы всё равно не помог

 
Ilia
22.01.2018
05:52:40
я не говорил, что бывают идеальные хэш функции. но хэш функция, которая возрастающие подряд числа мапит в одно число — плохая, без вариантов. это тот случай, когда отсутствие хэш функции лучше, тем такая. что я и предлагаю в своём пачте для бага
Не бывает плохих и хороших. Бывают подходящие и неподходящие

 
Alexey
22.01.2018
05:52:50
ахтыбожетымой та

 
Mike
22.01.2018
13:02:25
Добрый день. Подскажите пожалуйста. У меня есть таблица User (user_id|user_fio ) и таблица zayavleniya (zav_id, zav_user_zav_id, zav_user_podpis_id). Я пытаюсь вывести список документов из таблицы заявлений но фамилии не хотят разделяться если в колонке кто написал заявление написано ИВанов И.И. то и в колнке утверждения документа стоит Иванов И.И. хотя должен быть Петров В.В.

 


 
так вот должно выводиться, а в выводит что слева фамилия та и справа

 
Vladislav
22.01.2018
13:04:24
запрос покажите, но думаю, вам надо два раза обращаться к таблице user

 
Mike
22.01.2018
13:04:55
SELECT * FROM sog_inv left join users users.user_id = sog_inv.sog_inv_zayav_user_id

 
запрос покажите, но думаю, вам надо два раза обращаться к таблице user
напишите пожалуйста пример

 
Vladislav
22.01.2018
13:10:47
Например так: SELECT z.zayavlen_id, (SELECT u1.user_fio FROM user u1 WHERE z.user_zayavlen_id = u1.user_id) "написал", (SELECT u2.user_fio FROM user u2 WHERE z.user_utverd_id = u2.user_id) "подписал", FROM zayavlen z; или так: SELECT z.zayavlen_id, u1.user_fio "написал", u2.user_fio "подписал", FROM zayavlen z LEFT JOIN user u1 ON z.user_zayavlen_id = u1.user_id LEFT JOIN user u2 ON z.user_utverd_id = u2.user_id;

 
Александр
22.01.2018
13:11:39
первый плохой запрос, он же на каждую строку будет 2 подзапроса делать

 
второй норм, только в первом случае INNER JOIN у заявления же всегда есть заявитель =)

 
Vladislav
22.01.2018
13:12:13
первый плохой запрос, он же на каждую строку будет 2 подзапроса делать
и что? эти два подзапроса могут работать быстрее, чем два лефт джойна при большом количестве данных

 
второй норм, только в первом случае INNER JOIN у заявления же всегда есть заявитель =)
а это уже он сам решит, я взял, как он написал

 
у первого проблема, что если вдруг, каким то чудом, будет где-то две фамилии

Admin
ERROR: S client not available

 
Vladislav
22.01.2018
13:12:58
вот это да

Google
 
lost
22.01.2018
13:13:33
это нарушение нф, так что в таком случае так ему и надо...

 
Mike
22.01.2018
13:14:38
Сообщение 4104, уровень 16, состояние 1, строка 1 Не удалось привязать составной идентификатор "users.user_id". Сообщение 4104, уровень 16, состояние 1, строка 1 Не удалось привязать составной идентификатор "users.user_id

 
Vladislav
22.01.2018
13:16:19
Сообщение 4104, уровень 16, состояние 1, строка 1 Не удалось привязать составной идентификатор "users.user_id". Сообщение 4104, уровень 16, состояние 1, строка 1 Не удалось привязать составной идентификатор "users.user_id
это уже вопрос к вам, ибо на скриншоте одни данные (по ним и писал запрос), а в вашем примере другие

 
Mike
22.01.2018
13:16:35
буду разбираться спасибо

 
Vladislav
22.01.2018
13:16:46
я специально проименовал альясы по разному, чтобы вы понимали, что как и почему

 
Mike
22.01.2018
13:18:57
ок.

 
Александр
22.01.2018
13:21:20
с подзапросами ещё запрос по разному работает чем тот что с джоинами он выберет вообще все записи из таблицы пользователей, независимо от того есть заявления или нет а второй выдаст только данные касаемые заявлений

 
Vladislav
22.01.2018
13:22:19
с подзапросами ещё запрос по разному работает чем тот что с джоинами он выберет вообще все записи из таблицы пользователей, независимо от того есть заявления или нет а второй выдаст только данные касаемые заявлений
это как? что-то вы путаете

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

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

 
Александр
22.01.2018
13:28:51
да, оба лефт джоина же, вы правы

 
Ilia
22.01.2018
13:35:06
с подзапросами ещё запрос по разному работает чем тот что с джоинами он выберет вообще все записи из таблицы пользователей, независимо от того есть заявления или нет а второй выдаст только данные касаемые заявлений
Это кто тебе сказал?

 
Александр
22.01.2018
13:37:42
Это кто тебе сказал?
здравый смысл, там же в запросе не ограничивается никак

 
про left joinы тоже выберет всё

 
я просто такие запросы не использую рискованные

 
ибо данных есть чуть-чуть

 
Ilia
22.01.2018
13:38:27
Вообще надо смотреть запрос, но в принципе любое подобное утверждение априори неверно.

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

 
Александр
22.01.2018
13:39:55
когда я это писал, я почему то был твёрдо уверен что во втором запросе обычный джоин, тогда бы мой спич имел смысл, я был невнимателен

 
@Coldplay
23.01.2018
08:25:40
Ребят что такое qbe.

Google
 
Vladislav
23.01.2018
08:27:00
а что говорит гугл на эту тему?

 
Ilia
23.01.2018
08:30:55
Query by example

 
Ilgiz
23.01.2018
08:44:51
Ребят тут можно же задавать тупые вопросы по индексам в mysql?

 
Vladislav
23.01.2018
08:45:10
можно

 
Ilgiz
23.01.2018
08:46:03
я тут что-то делаю не правильно? создал индекс по gender для таблицы user_details create index gender user_details(gender) 0.11411000 | select username from user_details where gender='Male' limit 100000 0.24413500 | select username from user_details where gender='Male' limit 100000 без индекса запрос прошел быстрей с индексом обработал на 50% меньше записей но по времени почему-то дольше

Страница 390 из 718