2016-09-25 3 views
1

Я работаю с centos 7 и 10.1.8-MariaDB. Иногда я чувствую, что система медленная. Сегодня, проверяя медленные запросы, я видел, что запросы на обновление очень тонкие или обычно быстрые, чем на некоторых этапах более 3 или 4 секунд.MariaDB Performance

База данных запускается на выделенном сервере, только установленный mariadb. У него 4 ГБ.

Вот память:

cat /proc/meminfo 
MemTotal:  3883016 kB 
MemFree:   156380 kB 
MemAvailable:  293708 kB 
Buffers:    0 kB 
Cached:   288140 kB 
SwapCached:  171352 kB 
Active:   2546636 kB 
Inactive:  1023020 kB 
Active(anon): 2391628 kB 
Inactive(anon): 905344 kB 
Active(file):  155008 kB 
Inactive(file): 117676 kB 
Unevictable:   0 kB 
Mlocked:    0 kB 
SwapTotal:  2113532 kB 
SwapFree:  1334248 kB 
Dirty:     0 kB 
Writeback:    0 kB 
AnonPages:  3241692 kB 
Mapped:   20172 kB 
Shmem:    15456 kB 
Slab:    87216 kB 
SReclaimable:  67176 kB 
SUnreclaim:  20040 kB 
KernelStack:  3200 kB 
PageTables:  12088 kB 
NFS_Unstable:   0 kB 
Bounce:    0 kB 
WritebackTmp:   0 kB 
CommitLimit:  4055040 kB 
Committed_AS: 4645884 kB 
VmallocTotal: 34359738367 kB 
VmallocUsed:  160244 kB 
VmallocChunk: 34359568380 kB 
HardwareCorrupted:  0 kB 
AnonHugePages: 2045952 kB 
HugePages_Total:  0 
HugePages_Free:  0 
HugePages_Rsvd:  0 
HugePages_Surp:  0 
Hugepagesize:  2048 kB 
DirectMap4k:  59328 kB 
DirectMap2M:  4134912 kB 

Это my.cnf

my.cnf 
# 
# This group is read both both by the client and the server 
# use it for options that affect everything 
# 
[mysqld] 
bind-address = 0.0.0.0 

#tmp per carregar: 
wait_timeout=108000 
max_allowed_packet=40960M 

[client-server] 
# 
# include all files from the config directory 
# 
!includedir /etc/my.cnf.d 

[mysqld] 
# 20151031 
# charset 
# init_connect=.SET collation_connection = utf8_unicode_ci. 
# init_connect=.SET NAMES utf8. 
character-set-server=utf8 
collation-server=utf8_unicode_ci 

open_files_limit = 8192 
max_connections = 200 

slow-query-log = 1 
slow-query-log-file = /var/log/mariadb/mysql-slow.log 
long_query_time = 1 

#performance 
# innodb_buffer_pool_size default: 134217728 (128MB) - 60 o 70% memoria 
# 2048MB - 70% = 6012954214 (5734MB) 
innodb_buffer_pool_size=3GB 
innodb_buffer_pool_instances=3 

thread_cache_size=200 

#query_cache_size 
query_cache_type = 1 
query_cache_limit = 1M 
query_cache_min_res_unit = 2k 
query_cache_size = 80M 

#LOGS 
#log-error 
log_warnings = 3 
log-error = /var/log/mariadb/mariadb.log 

Медленный запрос журнала:

# [email protected]: swb[swb] @ [192.168.50.65] 
# Thread_id: 23002274 Schema: swb QC_hit: No 
# Query_time: 2.000710 Lock_time: 0.000209 Rows_sent: 0 Rows_examined: 1 
# Rows_affected: 1 
SET timestamp=1474793382; 
UPDATE instalaciones 
       SET 
        fSincro = now(), 
        tHotspot='ACTIVO' 
       WHERE tRouterSerial = '558104409B1B'; 



# [email protected]: swb[swb] @ [192.168.50.65] 
# Thread_id: 22499243 Schema: swb QC_hit: No 
# Query_time: 1.909591 Lock_time: 0.000041 Rows_sent: 0 Rows_examined: 0 
# Rows_affected: 1 
SET timestamp=1474636304; 
INSERT INTO redirect(tRedirect,fFecha) VALUES ('ff0005a8c8f2c409a1a5a58fab6d16b455d09258',now()); 

Определение таблицы:

CREATE TABLE `instalaciones` (
    `idInstalacion` int(10) unsigned NOT NULL AUTO_INCREMENT, 
    `idCliente` int(10) unsigned DEFAULT NULL, 
    `tRouterSerial` varchar(50) DEFAULT NULL, 
    `tFacebookPage` varchar(256) DEFAULT NULL, 
    `tidFacebook` varchar(64) DEFAULT NULL, 
    `tNombre` varchar(128) DEFAULT NULL, 
    `tMensaje` varchar(128) DEFAULT NULL, 
    `tWebPage` varchar(128) DEFAULT NULL, 
    `tDireccion` varchar(128) DEFAULT NULL, 
    `tPoblacion` varchar(128) DEFAULT NULL, 
    `tProvincia` varchar(64) DEFAULT NULL, 
    `tCodigoPosta` varchar(8) DEFAULT NULL, 
    `tLatitud` decimal(15,12) DEFAULT NULL, 
    `tLongitud` decimal(15,12) DEFAULT NULL, 
    `tSSID1` varchar(40) DEFAULT NULL, 
    `tSSID2` varchar(40) DEFAULT NULL, 
    `tSSID2_Pass` varchar(40) DEFAULT NULL, 
    `fSincro` datetime DEFAULT NULL, 
    `tEstado` varchar(10) DEFAULT NULL, 
    `tHotspot` varchar(10) DEFAULT NULL, 
    `fAlta` datetime DEFAULT NULL, 
    PRIMARY KEY (`idInstalacion`), 
    UNIQUE KEY `tRouterSerial` (`tRouterSerial`), 
    KEY `idInstalacion` (`idInstalacion`), 
    KEY `idCliente` (`idCliente`) 
) ENGINE=InnoDB AUTO_INCREMENT=1611 DEFAULT CHARSET=utf8; 

CREATE TABLE `redirect` (
    `tRedirect` varchar(80) DEFAULT NULL, 
    `fFecha` datetime DEFAULT NULL, 
    KEY `itRedirect` (`tRedirect`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8; 

Это объясняет

id select_type table type possible_keys key key_len ref rows Extra 
1 SIMPLE instalaciones range tRouterSerial tRouterSerial 153 NULL 1 "Using where" 


id select_type table type possible_keys key key_len ref rows Extra 
1 INSERT redirect ALL NULL NULL NULL NULL NULL NULL 

Это SHOW TABLE STATUS LIKE

Name,Engine,Version,Row_format,Rows,Avg_row_length,Data_length,Max_data_length,Index_length,Data_free,Auto_increment,Create_time,Update_time,Check_time,Collation,Checksum,Create_options,Comment 

instalaciones,InnoDB,10,Compact,1401,339,475136,0,131072,0,1611,"2016-06-28 22:20:45",NULL,NULL,utf8_general_ci,NULL,, 

Name Engine Version Row_format Rows Avg_row_length Data_length Max_data_length Index_length Data_free Auto_increment Create_time Update_time Check_time Collation Checksum Create_options Comment 
redirect InnoDB 10 Compact 30766 102 3162112 0 3162112 13631488 NULL "2016-02-22 09:57:20" NULL NULL utf8_general_ci NULL   

Может кто-нибудь помочь мне с этой медленной querys?

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

ОБНОВЛЕНО:

Это медленная форма запроса сегодня

# [email protected]: swb[swb] @ [192.168.50.65] 
# Thread_id: 23552588 Schema: swb QC_hit: No 
# Query_time: 1.279738 Lock_time: 0.000115 Rows_sent: 0 Rows_examined: 1 
# Rows_affected: 1 
SET timestamp=1474975258; 
UPDATE instalaciones 
       SET 
        fSincro = now(), 
        tHotspot='ACTIVO' 
       WHERE tRouterSerial = '558104B41762'; 
# Time: 160927 18:40:30 

и это mariadb.log со вчерашнего (ничего сегодня):

2016-09-26 12:53:49 140053608847104 [Warning] Aborted connection 23132533 to db: 'unconnected' user: 'SWB_BDA' host: '192.168.50.65' (Unknown error) 
2016-09-26 12:53:49 140053608249088 [Warning] Aborted connection 23132521 to db: 'swb' user: 'SWB_BDA' host: '192.168.50.65' (Unknown error) 
+0

проблемы параллелизма/блокировки? – Drew

+0

Привет, Дрю, много обновлений каждую минуту, это может быть параллелизм. Вероятно, на этих столах 100 запросов в минуту .. как это улучшить? Замки: я не блокирую столы ... насколько я знаю ... –

+0

Вы знакомы с запросом 'SHOW PROCESSLIST''? Изучение * того, что еще происходит *, пока сервер вялый, часто довольно просвещен. –

ответ

0

Насколько велика ваша база данных? 4G mem для сервера базы данных звучит очень мало. Вы проверили свой журнал ошибок? Вы также должны увидеть vmstat или подобное, чтобы узнать, что еще происходит, когда ваши запросы медленны. При условии, что примеры не должны быть медленными, если ничего не происходит.

+0

Привет, Ян, я обновил текущие mariadb.log и slowquery ... Журналы mariadb, похоже, не отображают ошибок, возможно, мне нужно увеличить какой-то уровень журнала, чтобы показать больше информации? Кто-нибудь знает, как это сделать? –

1

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

3GB для innodb_buffer_pool_size не подходит для 4-гигабайтного сервера. Рекомендуем изменить следующее:

max_allowed_packet=40960M  --> 50M 
innodb_buffer_pool_size=3GB  --> 1500M 
innodb_buffer_pool_instances=3 --> 1 
thread_cache_size=200   --> 10 
query_cache_size = 80M   --> 40M 
+0

Привет, Rickm, почему вы меняете innodb_buffer_pool_size на 1500M, это выделенный сервер с Centos и mariadb, который я читал, что в этом случае buffer_pool_size может быть 70% оперативной памяти .... Я увеличил этот параметр из-за mysqltuner (6 месяцев назад во время тестирования окружающая среда) –

+0

70% подходит для серверов размером более 4 ГБ. У 3G/4G у вас были и другие вещи, которые пережевывали RAM, вероятно, были объединены, чтобы вызвать обмен, что ужасно для производительности MySQL. Мой предложенный 1.5G может быть ниже, чем требуется, но он должен решить ближайшую проблему. –