2017-01-01 9 views
0

Я запускаю очень простую конструкцию базы данных MySQL. У меня есть только id, TimeStamp и OP_fs155e столбцы, которые я считаю чрезвычайно базовой настройкой.Низкая производительность MySQL в Centos 7

MariaDB [gadbdfm]> desc optical_power; 
+-----------+------------------+------+-----+----------------------+-----------------------------+ 
| Field  | Type    | Null | Key | Default    | Extra      | 
+-----------+------------------+------+-----+----------------------+-----------------------------+ 
| id_record | int(10) unsigned | NO | PRI | NULL     | auto_increment    | 
| TimeStamp | timestamp(6)  | NO |  | CURRENT_TIMESTAMP(6) | on update CURRENT_TIMESTAMP | 
| OP_fs155e | varchar(30)  | YES | MUL | NULL     |        | 
| data1  | varchar(30)  | YES |  | NULL     |        | 
| data2  | varchar(30)  | YES |  | NULL     |        | 
| data3  | varchar(30)  | YES |  | NULL     |        | 
| data4  | varchar(30)  | YES |  | NULL     |        | 
| data5  | varchar(30)  | YES |  | NULL     |        | 
+-----------+------------------+------+-----+----------------------+-----------------------------+ 
8 rows in set (0.00 sec) 

Однако, я начинаю замечать, что мои выбирает ужасно медленно первый в Raspberry Pi 3 (в качестве ведущего) и Centos7 (в качестве ведомого устройства - сервера мышц 8GB). Вот мой выбор всего на подчиненном сервере, который занял несколько минут. Я думал, что проблема в том, что Raspberry Pi 3 слишком медленный, но , когда я узнал, что это то же самое на реальном сервере-рабе, в нем есть что-то не так.

MariaDB [gadbdfm]> select TimeStamp,OP_fs155e from optical_power; 

| 2017-01-01 17:41:03.697000 | -24  | 
| 2017-01-01 17:42:03.666000 | -24  | 
| 2017-01-01 17:43:03.701000 | -24  | 
| 2017-01-01 17:44:03.675000 | -24  | 
| 2017-01-01 17:45:03.676000 | -24  | 
| 2017-01-01 17:46:03.692000 | -24  | 
| 2017-01-01 17:47:03.686000 | -24  | 
| 2017-01-01 17:48:03.539000 | -24  | 
| 2017-01-01 17:49:03.581000 | -24  | 
+----------------------------+-----------+ 
23044062 rows in set (37.24 sec) 

Мастер my.cnf

[email protected] - /opt/FlightStrata155E cat /etc/mysql/mysql.conf.d/mysqld.cnf | grep -v "#" | grep -v "^$" 
[mysqld_safe] 
socket  = /var/run/mysqld/mysqld.sock 
nice  = 0 
[mysqld] 
user  = mysql 
pid-file = /var/run/mysqld/mysqld.pid 
socket  = /var/run/mysqld/mysqld.sock 
port  = 3306 
basedir  = /usr 
datadir  = /var/lib/mysql 
tmpdir  = /tmp 
lc-messages-dir = /usr/share/mysql 
skip-external-locking 
bind-address  = 0.0.0.0 
key_buffer_size  = 16M 
max_allowed_packet = 16M 
thread_stack  = 192K 
thread_cache_size  = 8 
myisam-recover   = BACKUP 
query_cache_limit = 1M 
query_cache_size  = 16M 
log_error = /var/log/mysql/error.log 
server-id  = 1 
log_bin   = /var/log/mysql/mysql-bin.log 
expire_logs_days = 10 
max_binlog_size = 100M 
relay-log = /var/lib/mysql/mysql-relay-bin 
relay-log-index = /var/lib/mysql/mysql-relay-bin.index 
log-error = /var/lib/mysql/mysql.err 

Ведомый my.cnf:

[[email protected] ~]# cat /etc/my.cnf | grep -v "#" | grep -v "^$" 
[mysqld] 
datadir=/var/lib/mysql 
socket=/var/lib/mysql/mysql.sock 
symbolic-links=0 
server-id = 2 
[mysqld_safe] 
log-error=/var/log/mariadb/mariadb.log 
pid-file=/var/run/mariadb/mariadb.pid 
!includedir /etc/my.cnf.d 

Я знаю, что у меня есть нулевой оптимизации в моей схеме.

Еще один пример:

Это отборное на Raspberry Pi 3 принимает как 7 минут

mysql> select TimeStamp, OP_fs155e from optical_power ORDER BY TimeStamp desc limit 15; 
+0

показать нам выход из ** EXPLAIN выберите TimeStamp, OP_fs155e от optical_power ORDER BY TimeStamp предела по убыванию 15; ** –

+0

Итак, что мое приложение делает следующее: Как каждую минуту я собираю значение я называю ** OP_fs155e ** (оптическая мощность) от устройства свободной космической оптики и сохранить это в ** mysql ** на малине pi3 (MASTER). – user2156115

ответ

0

Ну, что касается вашего первого предложения:

Database changed 
mysql> SHOW TABLE STATUS LIKE 'optical_power'\G 
*************************** 1. row *************************** 
      Name: optical_power 
     Engine: InnoDB 
     Version: 10 
    Row_format: Compact 
      Rows: 22030014 
Avg_row_length: 38 
    Data_length: 843055104 
Max_data_length: 0 
    Index_length: 0 
     Data_free: 7340032 
Auto_increment: 34973978 
    Create_time: 2016-12-30 16:10:49 
    Update_time: NULL 
    Check_time: NULL 
     Collation: latin1_swedish_ci 
     Checksum: NULL 
Create_options: 
     Comment: 
1 row in set (0.00 sec) 

Я использую 16GB USB Toshiba Stick как память вместо SD SD-карты, потому что у меня так много проблем с SD-картами. Например, я использую все порты USB малины pi3 потому что необходимо собирать данные с нескольких датчиков. Я пытаюсь

ALTER TABLE optical_power ADD INDEX(TimeStamp,OP_fs155e); 

Я высоко ценю ваш ответ я буду стараться играть с ним.

Большое спасибо

Так что это как раз просто метка времени и значение (OP_fs155e) стол.

code mysql> select TimeStamp, OP_fs155e from optical_power ORDER BY TimeStamp desc limit 15; 
+----------------------------+-----------+ 
| TimeStamp     | OP_fs155e | 
+----------------------------+-----------+ 
| 2017-01-01 17:49:03.581000 | -24  | 
| 2017-01-01 17:48:03.539000 | -24  | 
| 2017-01-01 17:47:03.686000 | -24  | 
| 2017-01-01 17:46:03.692000 | -24  | 
| 2017-01-01 17:45:03.676000 | -24  | 
| 2017-01-01 17:44:03.675000 | -24  | 
| 2017-01-01 17:43:03.701000 | -24  | 
| 2017-01-01 17:42:03.666000 | -24  | 
| 2017-01-01 17:41:03.697000 | -24  | 
| 2017-01-01 17:40:03.688000 | -24  | 
| 2017-01-01 17:39:03.574000 | -24  | 
| 2017-01-01 17:38:03.596000 | -24  | 
| 2017-01-01 17:37:03.545000 | -24  | 
| 2017-01-01 17:36:03.667000 | -24  | 
| 2017-01-01 17:35:03.544000 | -24  | 
+----------------------------+-----------+ 
15 rows in set (2 min 41.32 sec) 
+0

То, что я искал, это 'Data_length: 843055104', который не слишком далеко от моей догадки 755 МБ. Состояние таблицы может отображать только приблизительные оценки строк, data_length, index_length. –

1

Малиновый Pi использует SD-карту для хранения, и поэтому понятно, что производительность ввода/вывода будет намного хуже, чем дисковая система реального сервера.

Ваш первый запрос, который занимает 37.24 секунды, чтобы вернуть 23 миллиона строк. Это совсем немного ввода-вывода. Я бы оценил, что вы могли бы разместить около 500 строк на страницу 16 КБ (при условии, что ваши столбцы данных в среднем составляют около 3 байтов), поэтому вам нужно будет прочитать более 46 000 страниц, чтобы читать 23 миллиона строк, которые выходят до 755 МБ.

Держу пари, что это более или менее data_length вашей таблицы, которые вы можете проверить:

SHOW TABLE STATUS LIKE 'optical_power'\G 

Но скорость ввода/вывода для случайного чтения на SD-карта находится между 2.28MB/с и 8.10MB/сек, поэтому для считывания 755 МБ с SD-карты потребуется от 93 до 331 секунд. Это просто математика.

Возможно, некоторые страницы данных уже были кешированы в буферном пуле MySQL, или InnoDB смог выполнить некоторые оптимизации чтения, чтобы помочь здесь.

Ваш второй запрос не оптимизирован хорошо. Он должен использовать fileort, потому что нет индекса в вашем столбце TimeStamp. Файлограмм может использовать временное пространство для хранения, которое влечет за собой ввод ввода-вывода. Записи намного медленнее, чем чтение на SD-карте. Поэтому совсем не удивительно, что для выполнения вашего запроса ORDER BY TimeStamp LIMIT 15 требуется 7 минут.

Видимо, марка SD-карты имеет большое значение. См. http://www.jeffgeerling.com/blogs/jeff-geerling/raspberry-pi-microsd-card для некоторых сравнений.

Но даже если вы получаете карту SD, которая работает быстрее, вы все равно наносите на нее износ, используя неэффективные входы/выходы. Лучше избегать ввода-вывода.

  • Создать индекс на вашей TimeStamp колонке, поэтому ORDER BY TimeStamp может использовать его вместо того, чтобы делать FileSort. Индексирование очень важно для оптимизации запросов. См. Мою презентацию How to Design Indexes, Really.
  • Многие пользователи Raspberry Pi хранят данные MySQL в модуле хранения MyISAM. MyISAM использует только буферизованный ввод-вывод и не имеет функций безопасности при столкновении. Это должно помочь улучшить производительность ввода-вывода и снизить износ на вашей SD-карте. Индексы и репликация отлично работают с таблицами MyISAM. MyISAM также имеет тенденцию хранить данные в меньшем пространстве, чем InnoDB.
  • Убедитесь, что вы установили sync_binlog=0, чтобы позволить журналу репликации использовать async I/O.

Если вы должны использовать InnoDB, настроить его для максимального кэширования и минимальной прочности:

  • Увеличьте innodb_buffer_pool_size столько, сколько вы можете сэкономить. Но не делайте его настолько большим, что другим процессам не хватает памяти. Подсчитайте буферный пул, используя еще 10%, поэтому, если вы установите его на 512M, он действительно займет 563M.
  • Избегайте синхронного ввода-вывода и используйте буферизованный ввод-вывод, где это возможно. См https://dev.mysql.com/doc/refman/5.5/en/optimizing-innodb-diskio.html

    innodb_flush_log_at_trx_commit=2 
    innodb_flush_method=O_DSYNC 
    innodb_doublewrite=0 
    

Re ваш комментарий:

Я использую 16GB USB Toshiba клюшку в качестве хранилища вместо спосо SD-карты, потому что я так много проблем с SD картами

USB-накопитель (ручка) не сильно отличается по сравнению с SD-картой. Оба устройства оптимизированы для последовательного чтения/записи, а не случайного чтения/записи. Они сосать ужасно, как файловые системы, или для работы с базами данных.

Суть в том, что вам нужна производительность реального сервера, с данными в масштабе, который принадлежит на сервере, а затем не используйте малину Pi.

Я ожидаю, что решение Raspberry Pi для сбора данных не будет хранить данные на Pi, а вместо этого опубликует данные немедленно на сервере в вашей сети. Хорошим решением было бы запустить сервер очереди сообщений, собирая события, размещенные вашими различными устройствами Pi. Затем напишите сценарий, чтобы потреблять данные из очереди сообщений и отправлять их в базу данных партиями.

0

Здравствуйте @Bill Karwin и @Bernd Buffen! Я высоко ценю ваш совет ! Я добавил как этот показатель, как показывают и объяснены в презентации here:

mysql> ALTER TABLE optical_power ADD INDEX(TimeStamp,OP_fs155e); 

и результат 3,24 секунд по сравнению с 2-х минут OT 7 минут иногда: ИЗУМИТЕЛЬНАЯ !!!

mysql> use gadbdfm; 
Database changed 
mysql> select TimeStamp, OP_fs155e from optical_power ORDER BY TimeStamp desc limit 15; 
+----------------------------+-----------+ 
| TimeStamp     | OP_fs155e | 
+----------------------------+-----------+ 
| 2017-01-01 17:49:03.581000 | -24  | 
| 2017-01-01 17:48:03.539000 | -24  | 
| 2017-01-01 17:47:03.686000 | -24  | 
| 2017-01-01 17:46:03.692000 | -24  | 
| 2017-01-01 17:45:03.676000 | -24  | 
| 2017-01-01 17:44:03.675000 | -24  | 
| 2017-01-01 17:43:03.701000 | -24  | 
| 2017-01-01 17:42:03.666000 | -24  | 
| 2017-01-01 17:41:03.697000 | -24  | 
| 2017-01-01 17:40:03.688000 | -24  | 
| 2017-01-01 17:39:03.574000 | -24  | 
| 2017-01-01 17:38:03.596000 | -24  | 
| 2017-01-01 17:37:03.545000 | -24  | 
| 2017-01-01 17:36:03.667000 | -24  | 
| 2017-01-01 17:35:03.544000 | -24  | 
+----------------------------+-----------+ 
15 rows in set (3.24 sec) 
+0

Этот запрос с этим индексом должен работать намного быстрее. –