[РЕШЕНО] Почти зависание при просмотре списка контрагентов

[netzmb]

При попытке просмотра списка контрагентов программа надолго (мягко говоря) задумывается. В терминал успевает выдать сообщение:

Код: Выделить всё

1173002 [main] INFO  -
OpenTable: select * from dpbase.listclorg where fwid =0


Во время обработки этого запроса mysqld загружает одно ядро процессора на 99%.

Код: Выделить всё

~ $ top -n 1 -u mysql -b
...
PID   USER     PR  NI  VIRT RES  SHR  S   %CPU  %MEM TIME+     COMMAND           
9023 mysql     20   0  177m 6352 1256 S   99    0.7  34:02.25  mysqld


Код: Выделить всё

mysql> SHOW PROCESSLIST;
+----+---------+-----------------+---------+---------+------+--------------+--------------------------------------------+
| Id | User    | Host            | db      | Command | Time | State        | Info                                       |
+----+---------+-----------------+---------+---------+------+--------------+--------------------------------------------+
|  2 | DPADMIN | localhost:43289 | dpadmin | Query   | 1589 | Sending data | select count(fisgrp) from dpbase.listclorg |
|  8 | root    | localhost       | dpbase  | Query   |    0 | NULL         | SHOW PROCESSLIST                           |
+----+---------+-----------------+---------+---------+------+--------------+--------------------------------------------+
2 rows in set (0.00 sec)


Экспериментальным путём выяснено, что за продолжительное время (программа оставлялась на ночь) запрос выполнялся и список контрагентов нормально отображался в DebetPlus. Если попытаться его обновить, или ещё каким-нибудь образом заставить перерисоваться этот список, то выполняется злополучный запрос "select count(fisgrp) from dpbase.listclorg" и "тормоза" повторяются снова.

Список контрагентов импортирован из dbf-файла, импорт говорит, что импортировано ~400 контрагентов. Для чистоты эксперимента специально импортировал информации по минимуму - только название предприятия и больше ничего.

Система: Gentoo linux 2.6.36-gentoo-r5
CPU: AMD Athlon II x2 x86_64
MySQL: 5.1.51
DebetPlus: официальный, свежескачанный с сайта

Вопрос: как избавиться от этих тормозов? Добавить какие-нибудь дополнительные индексы к участвующим в запросе таблицам? Чесно говоря, не понимаю до конца, с чем они связаны.


Update 2011-03-12 18:04

После обработки первого запроса, в терминале появились следующие тормозные запросы:

Код: Выделить всё

3857305 [main] INFO  -
getSnap - 2596415: select count(fisgrp) from dpbase.listclorg
3858077 [main] INFO  -
OpenTable: select * from dpbase.listclorg where  (fwid>0)  and  fisgrp<>0 and fwid <>0 order by fleftkey


Судя по всему, тормоза вообще свойственны любым операциям с таблицей "listclorg".

[Дарья]

Запустите переиндексацию: меню Сервис/Обновление структур БД, уберите все отметки для модификации и поставьте для переиндексации.

[netzmb]

Спасибо, переиндексация помогла

[netzmb]

Я выяснил причину пропажи индексов.

Ранее я хранил резервные копии базы в xml-е (вроде-бы более платформонезависимо и т.д). Когда заменял текущую базу резервной копией (через "импорт БД"), то судя по всему, вновь созданные таблицы не содержали индексов как таковых. Создавались просто таблички со столбцами и данными, указанным в xml-е, без индексов, формата MyISAM (вместо InnoDB).

Понятно, что без индексов как-то странно выглядел выхлоп EXPLAIN, когда каждый банальный select зацеплял тысячи строк вместо одной-двух-десятка нужных.

В общем, теперь буду знать, что при раскатывании данных из xml-ной резервной копии индексы не создаются, теоретически их можно создавать посредством "Обновления структур БД" (лень проверять )

Поэтому, чтобы быть полностью уверенным (не уверен, что "Обновление структур БД" сменит тип таблиц на InnoDB) в "правильности" таблиц, я просто наново пересоздал базу из начального дампа "dpbase.arh", потом её переиндексировал на всякий случай.

PS:
Специально провёл эксперимент - сравнил исходные таблицы (созданные из dpbase.arh) с позже созданными из xml:

Код: Выделить всё

mysql> SHOW COLUMNS FROM cl_12 like 'fmainwid';
+----------+-------------+------+-----+---------------------+-------+
| Field    | Type        | Null | Key | Default             | Extra |
+----------+-------------+------+-----+---------------------+-------+
| fmainwid | int(11)     | YES  | MUL | 0                   |       |
+----------+-------------+------+-----+---------------------+-------+


Формат таблицы: InnoDB, индекс есть

После восстановления из xml:

Код: Выделить всё

mysql> SHOW COLUMNS FROM cl_12 like 'fmainwid';
+----------+-------------+------+-----+---------------------+-------+
| Field    | Type        | Null | Key | Default             | Extra |
+----------+-------------+------+-----+---------------------+-------+
| fmainwid | int(11)     | YES  |     | 0                   |       |
+----------+-------------+------+-----+---------------------+-------+


Формат таблицы: MyISAM, индекса нет

[Дарья]

При восстановлении базы из arh индексировать не нужно.
При восстановлении из xml или mdb - обязательно.

Сама делаю так при сборке версии с базами разных СУБД. Так что проверено

[netzmb]

Спасибо за ответ!

Вот у меня возник встречный вопрос - а почему бы вам не подправить программу, чтобы она при импорте из xml/mdb по умолчанию создавала таблицы формата InnoDB? А то получается, что в случае использования .arh файла создаётся InnoDB, а во всех остальных случаях - MyISAM.
Где справедливость?

Просто в конце инструкции создания таблицы для варианта с MySQL добавить "ENGINE=InnoDB":

Код: Выделить всё

CREATE TABLE zames (
...
) ENGINE=InnoDB;


[Дарья]

Если в администраторе mysql стоит MyISAM, то при импорте из arh с последующей модификацией базы таблицы перебиваются в MyISAM. После чего и в xml будет выгружаться в MyISAM. Т.е. сначала устанавливаем InnoDB в настройках mysql, а потом импортируем базу.
А вообще предложение неплохое, спасибо.

[netzmb]

В целом, согласен

Действительно, использование MyISAM в базе с финансовой информацией несколько неоправдано, т.к. этот формат не поддерживает транзакции. Максимум, что должно позволяться в DP - это смена формата по умолчанию с InnoDB на MyISAM для тех экзотических случаев, когда пользователь базы MySQL по каким-то причинам не может использовать InnoDB (например, когда база хранится на каком-нибудь хостинге или типа того).

А вот по поводу общесистемной смены формата таблиц по умолчанию, это конечно выход, но на мой взгляд, имеющий "подводные камни".

Пока официально в MySQL для вновьсозданных таблиц по умолчанию используется MyISAM, теоретически могут возникнуть проблемы у другого софта, пользующегося тем-же сервером БД, что и DebetPlus. Некоторые программы могут предполагать, что по они создают таблицы в MyISAM, а они создаваться будут в InnoDB, что может вызвать какие-нибудь проблемы совместимости, или нецелевое расходование дискового пространства например.

Да, действительно неплохо было-бы реализовать эту функциональность (формат по умолчанию) локально, в рамках программы (закопать куда-нибудь в опции).

[netzmb]

Чесно говоря, не нашёл на форуме ветки типа "Предложения по улучшению программы", поэтому пока пишу тут.

Есть неплохая, наверное, довольно востебованная идея - почему-бы не создать программу-мастер для заливки данных в базу MySQL из начального .arh файла?
Чтобы человек в большинстве случаев мог просто вбить пароль root'а, пароль DPADMIN'a(опционально) и нажать кнопочку "Продолжить", после чего мастер сам автоматом создавал бы нужных пользователей в БД, раздал им права и на выходе получалась бы вполне рабочая база.

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

Теоретически, если GUI взять по минимуму, то написать такую довольно пустячную утилиту - для программиста делов на час работы . Дюжина SQL строчек и немного связующего кода. И всё

Кстати, после этого инструкцию по установке на MySQL можно прилично сократить.

[Дарья]

Вы не поверите, это уже сделали, кроме добавления пользователей

[barbos]

Вы не поверите, это уже сделали, кроме добавления пользователей

А где найти то что уже сделалали ?

Простая вроде бы задача по миграции программы с диска на диск (после переустановки Винды)
вызывает кучу проблем ...
Вроде все наладилось, но - зарплата перестала считаться (табеля не формируются).

[Дарья]

Войдет в следующую версию, будем надеяться

ЗЫ: если правильно все переносить, то таких проблем не возникает. Значит что-то упускаете...

[barbos]

Нашел ошибку (путь к базе).
Не нашел календарей - создал на март.
Однако табеля по-прежнему не формируются ...

[barbos]

Уже откопал где ошибка - не были введены нормы времени.
Раньше их по-моему не вводил - видимо они были уже введены в инсталяцию (на 2010г.) ?

[Дарья]

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