Есть таблица:
CREATE TABLE IF NOT EXISTS `stat_page_generation_mem` (
`datetime` datetime NOT NULL,
`page` varchar(255) NOT NULL,
`time` double NOT NULL,
`mem` double NOT NULL,
`qs` varchar(4096) NOT NULL,
`sid` char(38) NOT NULL,
`contacts_id` int(10) unsigned NOT NULL DEFAULT '0',
`remote_addr` int(10) unsigned NOT NULL DEFAULT '0',
`x_forwarded_for` varchar(35) DEFAULT NULL
) ENGINE=MEMORY

В нее идут insert-ы типа:
INSERT DELAYED INTO stat_page_generation_mem (datetime, page, time, mem, qs, sid, contacts_id, remote_addr, x_forwarded_for)VALUES ( '2015-02-25 15:10:47', '/page.phtml', '0.0618','2','id=3035', '','0', '111173434', '')
INSERT DELAYED INTO stat_page_generation_mem (datetime, page, time, mem, qs, sid, contacts_id, remote_addr, x_forwarded_for)VALUES ( '2015-02-25 15:12:53', '/page2.phtml', '0.069155216217041','1.75','group_id=41&page=20&a=0&st=name', '','', '621238157', '')

Причем этих инсертов не много (2-3 в секунду). Большинство проходит быстро, но некоторые выполняются до 1 секунды. Подскажите, пожалуйста, почему такое может происходить?

Без DELAYED тоже самое. Точнее DELAYED я только сегодня подставил в надежде...

miksoftandykid,

Свопа, случаем, нет? Что с расходом оперативки?

MEMORY USAGE
Max Memory Ever Allocated : 1.34 G
Configured Max Per-thread Buffers : 2.13 G
Configured Max Global Buffers : 960 M
Configured Max Memory Limit : 3.07 G
Physical Memory : 7.97 G
Max memory limit seem to be within acceptable norms

Вроде все нормально. Тут что-то другое. Сотня инсертов проходит за 0.00050сек., один-два за 0.5-1 секунду. Таблица в памяти, индексов нет, инсерт не тяжелый. Если с селектами я хоть примерно знаю куда копать (профилирование), тут у меня даже идей нет...

netwindНаличие и активность работы с swap вы не проверили.
Если верить топу, то в свапе не mysql. В любом случае после перезагрузок swap очень долго пустой.

top - 13:15:29 up 8 days, 12:50, 2 users, load average: 0.46, 0.29, 0.25
Tasks: 231 total, 2 running, 229 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.3%us, 0.3%sy, 0.0%ni, 98.2%id, 0.1%wa, 0.0%hi, 0.0%si, 0.1%st
Mem: 8365612k total, 7745008k used, 620604k free, 71220k buffers
Swap: 30716k total, 2632k used, 28084k free, 6260848k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP COMMAND
26054 mysql 20 0 4830m 435m 6800 S 4.6 5.3 19:42.67 0 mysqld
28024 apache 20 0 807m 41m 19m S 3.6 0.5 0:07.60 0 httpd
30763 apache 20 0 808m 38m 16m S 2.7 0.5 0:03.26 0 httpd
31310 apache 20 0 587m 27m 8560 R 1.7 0.3 0:00.10 0 httpd
29039 apache 20 0 806m 37m 14m S 1.3 0.5 0:02.35 0 httpd
29724 apache 20 0 808m 40m 18m S 1.3 0.5 0:02.53 0 httpd
31268 apache 20 0 732m 32m 12m S 1.3 0.4 0:00.69 0 httpd
31273 apache 20 0 659m 28m 9504 S 1.3 0.4 0:00.80 0 httpd
и т.д.

netwindТем не менее - профилирование. Снова. Оно работает и для insert.
Спасибо. С первого раза не разобрался как включить. Думал не работает. Плохо только то, что оно под консолью работает. А там запросы, как назло, быстро пролетают.

miksoftandykid,
И что за сервер? не дешевый VPS, случаем?
Сейчас flops (12 ядер, 8Гб память). Был Clodo примерно та же конфигурация. И те же проблемы.

Да, в медленный лог попадают. Время блокировки бывает разным. Обычно (99% записей)
# Query_time: 4.434586 Lock_time: 0.000088 Rows_sent: 0 Rows_examined: 0
Но нашел и такое.
# Query_time: 8.094332 Lock_time: 2.829994 Rows_sent: 0 Rows_examined: 0

Я не думаю, что это из-за клиентов. Скорее одновременная попытка записать...

По профилированию, у всех запросов большой query end (относительно, конечно):
mysql> show profile for query 9;
| starting | 0.000082 |
| checking permissions | 0.000012 |
| Opening tables | 0.000045 |
| System lock | 0.000011 |
| init | 0.000021 |
| update | 0.000049 |
| Waiting for query cache lock | 0.000004 |
| update | 0.000019 |
| end | 0.000005 |
| query end | 0.018637 |
| closing tables | 0.000039 |
| freeing items | 0.000040 |
| logging slow query | 0.000003 |
| cleaning up | 0.000004 |

Мне это не то, чтобы особо мешает. Просто была проведена работа по оптимизации запросов и остались только эти инсерты. Плюс мысли на будущее, что будет при увеличение нагрузки... Да и вообще, почему так. Я тоже не очень верю, что это проблема из-за типа таблицы, но тогда в чем еще может дело.

Репликации нет. Конфиг ниже. pt-summary еще ниже.

[mysqld]
default-time-zone='+3:00'
init-connect='SET NAMES cp1251'
default-storage-engine=myisam
skip-external-locking
skip-innodb
long_query_time=3
slow-query-log
#log-queries-not-using-indexes
skip-name-resolve
port = 3306
socket = /data/mysql/mysql.sock
datadir = /data/mysql/
max_connections =120
key_buffer_size = 768M
max_allowed_packet = 1M
table_open_cache = 220000
table_definition_cache=1000
sort_buffer_size = 4M
read_buffer_size = 4M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 102M
bulk_insert_buffer_size=32M
thread_cache_size = 8
thread_concurrency = 32
low_priority_updates=1
server-id = 1
uery_cache_min_res_unit=1
#query_cache_limit=32M
query_cache_size = 32M
character-set-server=utf8
collation-server=utf8_unicode_ci
max_heap_table_size=512M
tmp_table_size=512M
tmpdir=/tmp/
wait_timeout=50
interactive_timeout=50
join_buffer_size=4M
#binlog
log-bin=mysqld-bin
sync_binlog = 1
binlog_cache_size = 4M


# Percona Toolkit System Summary Report ######################
Date | 2015-02-26 15:22:46 UTC (local TZ: MSK +0300)
Uptime | 8 days, 17:57, 1 user, load average: 0.20, 0.27, 0.27
Platform | Linux
Release | CentOS release 6.6 (Final)
Kernel | 3.10.65-1.el6.elrepo.x86_64
Architecture | CPU = 64-bit, OS = 64-bit
Threading | NPTL 2.12
SELinux | Disabled
Virtualized | KVM
# Processor ##################################################
Processors | physical = 1, cores = 12, virtual = 12, hyperthreading = no
Speeds | 12x2000.000
Models | 12xIntel Xeon E5 (Sandy Bridge)
Caches | 12x4096 KB
# Memory #####################################################
Total | 8,0G
Free | 641,0M
Used | physical = 7,4G, swap allocated = 30,0M, swap used = 2,6M, virtual = 7,4G
Buffers | 69,6M
Caches | 6,0G
Dirty | 120 kB
UsedRSS | 2,1G
Swappiness | 60
DirtyPolicy | 20, 10
DirtyStatus | 0, 0
# Mounted Filesystems ########################################
Filesystem Size Used Type Opts Mountpoint
/dev/vda2 40G 29% ext4 rw /
tmpfs 1,5G 11% tmpfs rw,size=1500m,mode=1777 /dev/shm
# Disk Schedulers And Queue Size #############################
vda | [cfq] 128
# Disk Partioning ############################################
Device Type Start End Size
============ ==== ========== ========== ==================
/dev/vda Disk 42949672960
/dev/vda1 Part 2048 63487 31456768
/dev/vda2 Part 63488 83886078 42917166080
# Kernel Inode State #########################################
dentry-state | 135758 107849 45 0 0 0
file-nr | 1152 0 48000
inode-nr | 115873 20181
# LVM Volumes ################################################
Unable to collect information
# LVM Volume Groups ##########################################
Unable to collect information
# RAID Controller ############################################
Controller | No RAID controller detected
# Network Config #############################################
FIN Timeout | 60
Port Range | 61000
# Interface Statistics #######################################
interface rx_bytes rx_packets rx_errors tx_bytes tx_packets tx_errors
========= ========= ========== ========== ========== ========== ==========
lo 2500000000 10000000 0 2500000000 10000000 0
eth0 0 0 0 35000 400 0
eth1 3500000000 20000000 0 2250000000 20000000 0
# Network Devices ############################################
Device Speed Duplex
========= ========= =========
eth0
eth1
# Network Connections ########################################
Connections from remote IP addresses
127.0.0.1 30
ext-ip 90
Connections to local IP addresses
127.0.0.1 30
ext-ip 100
Connections to top 10 local ports
3306 20
57714 1
57715 1
57717 1
57718 1
57719 1
57720 1
57721 1
57722 1
57723 1
States of connections
ESTABLISHED 7
FIN_WAIT2 10
LISTEN 6
TIME_WAIT 150
# Top Processes ##############################################
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5454 apache 20 0 833m 71m 16m S 23.6 0.9 0:02.46 httpd
5560 apache 20 0 803m 30m 10m S 7.9 0.4 0:00.45 httpd
20313 mysql 20 0 1664m 257m 6680 S 7.9 3.1 4:00.25 mysqld
2369 root 20 0 2048m 11m 2188 S 3.9 0.1 233:01.77 fail2ban-server
21 root 20 0 0 0 0 S 2.0 0.0 37:56.21 rcu_sched
30 root 20 0 0 0 0 S 2.0 0.0 2:57.31 rcuos/8
6041 apache 20 0 655m 21m 4112 S 2.0 0.3 0:00.02 httpd
1 root 20 0 19284 1580 1308 S 0.0 0.0 0:02.23 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.04 kthreadd
# Notable Processes ##########################################
PID OOM COMMAND
1403 -17 sshd
# Simplified and fuzzy rounded vmstat (wait please) ##########
procs ---swap-- -----io---- ---system---- --------cpu--------
r b si so bi bo ir cs us sy il wa st
1 0 0 0 10 15 0 2 1 0 98 0 0
1 0 0 0 0 200 3000 4500 4 3 92 0 2
0 0 0 0 0 0 250 450 0 0 100 0 0
1 0 0 0 0 0 150 300 0 0 100 0 0
0 0 0 0 0 20 450 900 1 0 98 1 0
# The End ####################################################

Этот конфиг правился лет 10 наверное:) Некоторые параметры я не могу объяснить почему так. Но, где копать, понял, спасибо!

про query_cache_min_res_unit=1
Я не правильно понимаю его? Разве это не кэширование ответов сервера с размером в 1 байт? Есть много запросов, которые возвращают результат такого размера. Условно есть таблица приходов и таблица расходов. Запрос тяжелый, но результат свободное кол-во товара, к примеру 5. Просчитывать по крону - не вариант.

P.S. Похоже бинлог! Уже 3 минуты нет выпаданий:) Спасибо!

Ясно. Спасибо.