P
Я правильно понимаю, что сравниваются разные железки, разные версии мускуля, разные конфиги, немного разные базы и нагрузка? Это же нарушает основное правило инженера «не крути две ручки сразу»?
Size: a a a
2020 February 25
꧁
Я бы ещё на частоту цпу посмотрел, какая разница
M
Я их не сравниваю, на мой взгляд просто очень странно, что сервер с более высокими характеристиками, чем мой ПК работает в 10 раз медленнее, и клиент жалуется.
N
Тут дело не в сервере , а в системе ввода вывода
M
Что может быть не так?
time dd if=/dev/zero of=TEST bs=1M count=200
Дает 2 гб/с
time dd if=/dev/zero of=TEST bs=1M count=200
Дает 2 гб/с
VO
всё. и вообще это не имеет отношения к проблеме
N
dd пишет в кэш, насколько я помню
N
А вам нужно записать в кэш и синкнуть
M
А как понять в чем проблема? Кстати, мускл в докере, это может влиять?
PS
Что может быть не так?
time dd if=/dev/zero of=TEST bs=1M count=200
Дает 2 гб/с
time dd if=/dev/zero of=TEST bs=1M count=200
Дает 2 гб/с
стоит попробовать /dev/random, а не zero - ОС может оптимизировать запись нулей
M
time dd if=/dev/random of=TEST bs=1M count=200
dd: warning: partial read (116 bytes); suggest iflag=fullblock
^C0+39 records in
0+39 records out
528 bytes (528 B) copied, 195.844 s, 0.0 kB/s
real 3m15.845s
user 0m0.002s
sys 0m0.002s
dd: warning: partial read (116 bytes); suggest iflag=fullblock
^C0+39 records in
0+39 records out
528 bytes (528 B) copied, 195.844 s, 0.0 kB/s
real 3m15.845s
user 0m0.002s
sys 0m0.002s
Э
urandom
M
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 1.18815 s, 177 MB/s
real 0m1.191s
user 0m0.001s
sys 0m1.158s
200+0 records out
209715200 bytes (210 MB) copied, 1.18815 s, 177 MB/s
real 0m1.191s
user 0m0.001s
sys 0m1.158s
VY
диски
fio тестируютAT
Nikolay
Убрали. Если сервер упадет в это время , то все потеряется. Теперь гарантий дьюрабили нет
а вы пробовали innoDB выключать даже с коммитом =1 брать например и сервак из розетки выдернуть?
часто у вас потом заводилось так что данные не приходилось из бакапа доставать?
часто у вас потом заводилось так что данные не приходилось из бакапа доставать?
AT
у меня (и не только у меня) такого не получалось практически никогда...
AT
вот tokudb кстати - вот этот восстанавливал на ура, когда уже думаешь ну вот все, 3 секунды и база в бою
M
sudo fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=fiotest --filename=fiotest --bs=4k --iodepth=64 --size=4G --readwrite=randwrite
fiotest: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.7
Starting 1 process
fiotest: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [w(1)][100.0%][r=0KiB/s,w=31.9MiB/s][r=0,w=8163 IOPS][eta 00m:00s]
fiotest: (groupid=0, jobs=1): err= 0: pid=3234: Tue Feb 25 17:35:09 2020
write: IOPS=8554, BW=33.4MiB/s (35.0MB/s)(4096MiB/122570msec)
bw ( KiB/s): min= 72, max=94368, per=99.97%, avg=34207.77, stdev=13211.31, samples=245
iops : min= 18, max=23592, avg=8551.93, stdev=3302.83, samples=245
cpu : usr=3.59%, sys=17.63%, ctx=501273, majf=0, minf=26
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
issued rwts: total=0,1048576,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=64
Run status group 0 (all jobs):
WRITE: bw=33.4MiB/s (35.0MB/s), 33.4MiB/s-33.4MiB/s (35.0MB/s-35.0MB/s), io=4096MiB (4295MB), run=122570-122570msec
Disk stats (read/write):
md1: ios=140/1399800, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=70/1066560, aggrmerge=0/337649, aggrticks=43/3313502, aggrin_queue=2519886, aggrutil=76.69%
nvme0n1: ios=139/1066560, merge=0/337649, ticks=87/311552, in_queue=165374, util=18.56%
nvme1n1: ios=1/1066560, merge=0/337649, ticks=0/6315453, in_queue=4874398, util=76.69%M
Что-то не очень вроде?
AT
да не в дисках тут дело, скорее всего дело в блокировках - у вас там не было случайно никакого long running select, которого ждали 15 минут