Поможет ли tarantool в OpenVZ?

У меня есть маленький контейнер OpenVZ. 2 ядра и 4096 МБ оперативной памяти.

У меня есть база данных MySQL (общий размер 80 МБ InnoDb)

Когда я делаю 100 запросов, таких как INSERT ON DUPLICATE KEY UPDATE, некоторые из них выполняются дольше 1 секунды, всегда

mysql> SHOW PROFILE;
+----------------------+----------+
| Status               | Duration |
+----------------------+----------+
| checking permissions | 0.000040 |
| creating table       | 0.000056 |
| After create         | 0.011363 |
| query end            | 1.231525 |
| freeing items        | 0.000089 |
| logging slow query   | 0.000019 |
| cleaning up          | 0.000005 |
+----------------------+----------+
7 rows in set (0.00 sec)

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

Поможет ли это, если я заменю mysql на tarantool? Как я знаю, Tarantool также пишет binlogs.

У меня есть Percona MySQL

mysql> select version();
+-----------------+
| version()       |
+-----------------+
| 5.6.25-73.1-log |
+-----------------+
1 row in set (0.01 sec)

Вот мой.cnf

[client]
default-character-set = utf8mb4
[mysql]

# CLIENT #
port                           = 3306
socket                         = /var/lib/mysql/mysql.sock
default-character-set = utf8mb4

[mysqld]
character-set-client-handshake = FALSE
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci

# GENERAL #
user                           = mysql
default-storage-engine         = InnoDB
socket                         = /var/lib/mysql/mysql.sock
pid-file                       = /var/lib/mysql/mysql.pid

# MyISAM #
key-buffer-size                = 32M
myisam-recover                 = FORCE,BACKUP

# SAFETY #
max-allowed-packet             = 16M
max-connect-errors             = 1000000

# DATA STORAGE #
datadir                        = /var/lib/mysql/

# BINARY LOGGING #
#log-bin                        = /var/lib/mysql/mysql-bin
#expire-logs-days               = 14
#sync-binlog                    = 1

# CACHES AND LIMITS #
tmp-table-size                 = 128M
max-heap-table-size            = 128M
query-cache-type               = 1
query-cache-size               = 32M
max-connections                = 1000
thread-cache-size              = 128
open-files-limit               = 65535
table-definition-cache         = 1024
table-open-cache               = 2048

# INNODB #
innodb-flush-method            = O_DIRECT
innodb-log-files-in-group      = 2
innodb-log-file-size           = 256M
innodb_log_buffer_size         = 32M
innodb-flush-log-at-trx-commit = 0
innodb-file-per-table          = 1
innodb-buffer-pool-size        = 1G
innodb_buffer_pool_instances   = 1

# LOGGING #
log-error                      = /var/lib/mysql/mysql-error1.log
log-queries-not-using-indexes  = 1
slow-query-log                 = 1
slow-query-log-file            = /var/lib/mysql/mysql-slow.log
long_query_time                = 1
log-queries-not-using-indexes  = 1
#PERCONA
log_slow_verbosity = microtime,query_plan,innodb
Источник

2 ответа

Да Tarantool пишет "binlogs" (WAL - запись с опережением записи).

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

Источник

Тарантул должен помочь вам здесь.

Он обеспечивает задержку менее 0,001 с даже при включенном журнале транзакций. Вот фрагмент кода, который помогает вам тестировать Tarantool в условиях высокой нагрузки чтения / записи: https://gist.github.com/danikin/a5ddc6fe0cedc6257853.

Источник
Другие вопросы по тегам