ru.unix.bsd

Hello, Alex! SA>> Если для zfs нашел мануал где более менее все собpано в кучу AK> innodb_doublewrite=0 - вот с этим поаккуратней. Были сигналы - не чай он там AK> пьет! Как пишут: InnoDB использует метод потока файла, названный doublewrite. Перед записью страниц в файлы данных InnoDB сначала пишет их в непрерывную область, названную буфером doublewrite. Только после того, как запись и сброс к буферу doublewrite завершились, InnoDB пишет страницы к их надлежащим позициям в файле с данными. Если есть катастрофический отказ операционной системы, подсистемы хранения или процесса mysqld в середине записи страницы, InnoDB может позже найти хорошую копию страницы из буфера doublewrite во время восстановления катастрофического отказа. Хотя данные всегда пишутся дважды, буфер doublewrite не требует вдвое большего количества ввода/вывода. Данные написаны в буфер непосредственно как большой последовательный кусок одним вызовом fsync(). Чтобы выключить буфер doublewrite, определите опцию innodb_doublewrite=0 . AK> Правда, это про линуксы, у них и aio нарисованный, и вообще все через анус. Так ну типа если будет "катастрофический отказ операционной системы", что на говенном железе вполне может, печально будет, но правда это и про другие ручки можно сказать которые там крутятся ))) Ну тут имеется ввиду нормальные кейзы, так что статью принимать для себя имхо только с учетом своих условий. Ну и да там линукс. Хотя че говорить если в БСД уже Zol скоро будет наверно по дефолту :) С наилучшими пожеланиями, Sergey Anohin.

From: Alex Korchmar Eugene Grosbein wrote: EG> Размер страницы InnoDB и размер блока UFS крайне желательно EG> иметь одинаковыми и изменить размер страницы однажды созданной базы InnoDB я, кстати, рекомендую еще разок перечитать вот это из найденной пострадавшим компилятивной доки: As discussed above, ZFS LZ4 compression is incredibly fast, so we should leave compression to ZFS and not use InnoDBs built in page compression. As an added benefit, leaving compression to ZFS doesnt disrupt the block alignment. Optimising the storage stack for 16KB writes and then using compression at InnoDB level would То есть, если не планируется делать чего-то совсем странного, про страдания с попаданием в page size можно смело забывать - это in-memory pages, при записи все будет пожамкано в непредсказуемый размер. Читается оно с prefetch, поэтому никто от этого особо не страдает. (Hо вот размер записи в логи - насколько я понимаю, фиксированный.) > Alex

From: Alex Korchmar Sergey Anohin wrote: SA> Если для zfs нашел мануал где более менее все собpано в кучу innodb_doublewrite=0 - вот с этим поаккуратней. Были сигналы - не чай он там пьет! Правда, это про линуксы, у них и aio нарисованный, и вообще все через анус. Хотя через пару лет выбора уже не будет. > Alex

Hello *Alex* *Korchmar* AK> в pазмеp стpаницы ты все pавно не попадешь, поэтому пофигу чего ты там AK> будешь делать. Бэкап делай. Если для zfs нашел мануал где более менее все собpано в кучу https://shatteredsilicon.net/blog/2020/06/05/mysql-mariadb-innodb-on-zfs/ Bye, Alex Korchmar, 12 янваpя 21

Hello, Alex! AK> в размер страницы ты все равно не попадешь, поэтому пофигу чего ты там AK> будешь делать. Бэкап делай. xtrabackup трудится ночами, пока мускуль на zfs сидит провожу опыты с secondary/primary cache metadata С наилучшими пожеланиями, Sergey Anohin.

Hello *Eugene* *Grosbein* SA>> То есть так сойдет: SA>> newfs -f 16k -U -t /dev/ada2p2 SA>> /dev/ada2p2: 60664.3MB (124240480 sectors) block size 32768, SA>> fragment size 16384 EG> Паpдон, newfs -b 16k, а не newfs -f 16k. Я уж доку полез поднимать (пpавда винтажную): bsize - пеpвоначальный pазмеp блоков для файлов файловой системы, выбиpаемый из 4096 (по умолчанию) или 8192; fragsize - наименьшее пpостpанство на диске, котоpое выделяется для файла. Значение должно быть степенью числа 2, выбpанное из диапазона от 512 до 8192. Значение по умолчанию 1024; :)) Коpоче так: newfs -b 16k -U -t /dev/ada2p2 /dev/ada2p2: 60664.3MB (124240480 sectors) block size 16384, fragment size 4096 using 211 cylinder groups of 288.67MB, 18475 blks, 36992 inodes. Купил сpаный китайский ссд, его не жалко, Device Model: SSD 128GB Serial Number: 202011090492 LU WWN Device Id: 0 000000 000000000 Firmware Version: FW200326 User Capacity: 128 035 676 160 bytes [128 GB] Sector Size: 512 bytes logical/physical Rotation Rate: Solid State Device Form Factor: 2.5 inches Device is: Not in smartctl database [for details use: -P showall] ATA Version is: ACS-2 T13/2015-D revision 3 SATA Version is: SATA 3.2, 6.0 Gb/s (current: 3.0 Gb/s) Local Time is: Mon Jan 11 13:43:29 2021 MSK SMART support is: Available - device has SMART capability. SMART support is: Enabled хочу посмотpеть с ним как две вещи будут pаботать. Половину диска скоpмил под кеш ZFS, половину под MySQL скоpмлю. # diskinfo -i -c -t /dev/ada2p1 /dev/ada2p1 512 # sectorsize 64424509440 # mediasize in bytes (60G) 125829120 # mediasize in sectors 0 # stripesize 20480 # stripeoffset 124830 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. SSD 128GB # Disk descr. 202011090492 # Disk ident. Yes # TRIM/UNMAP support 0 # Rotation rate in RPM I/O command overhead: time to read 10MB block 1.434327 sec = 0.070 msec/sector time to read 20480 sectors 217.462525 sec = 10.618 msec/sector calculated command overhead = 10.548 msec/sector Seek times: Full stroke: 250 iter in 1.234495 sec = 4.938 msec Half stroke: 250 iter in 0.372980 sec = 1.492 msec Quarter stroke: 500 iter in 0.837252 sec = 1.675 msec Short forward: 400 iter in 3.022229 sec = 7.556 msec Short backward: 400 iter in 2.724871 sec = 6.812 msec Seq outer: 2048 iter in 12.909476 sec = 6.303 msec Seq inner: 2048 iter in 14.359088 sec = 7.011 msec Transfer rates: outside: 102400 kbytes in 3.272118 sec = 31295 kbytes/sec middle: 102400 kbytes in 3.279991 sec = 31220 kbytes/sec inside: 102400 kbytes in 1.620788 sec = 63179 kbytes/sec Asynchronous random reads: sectorsize: 1400 ops in 3.541322 sec = 395 IOPS 4 kbytes: 768 ops in 4.003832 sec = 192 IOPS 32 kbytes: 550 ops in 4.333299 sec = 127 IOPS 128 kbytes: 440 ops in 4.592614 sec = 96 IOPS (pts/1)[root@server:~]# diskinfo -i -c -t /dev/ada2p2 /dev/ada2p2 512 # sectorsize 63611125760 # mediasize in bytes (59G) 124240480 # mediasize in sectors 0 # stripesize 20480 # stripeoffset 123254 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. SSD 128GB # Disk descr. 202011090492 # Disk ident. Yes # TRIM/UNMAP support 0 # Rotation rate in RPM I/O command overhead: time to read 10MB block 0.944074 sec = 0.046 msec/sector time to read 20480 sectors 129.552573 sec = 6.326 msec/sector calculated command overhead = 6.280 msec/sector Seek times: Full stroke: 250 iter in 0.159767 sec = 0.639 msec Half stroke: 250 iter in 0.481089 sec = 1.924 msec Quarter stroke: 500 iter in 0.688598 sec = 1.377 msec Short forward: 400 iter in 1.164975 sec = 2.912 msec Short backward: 400 iter in 0.571858 sec = 1.430 msec Seq outer: 2048 iter in 3.764968 sec = 1.838 msec Seq inner: 2048 iter in 3.252936 sec = 1.588 msec Transfer rates: outside: 102400 kbytes in 1.625704 sec = 62988 kbytes/sec middle: 102400 kbytes in 1.289498 sec = 79411 kbytes/sec inside: 102400 kbytes in 4.554813 sec = 22482 kbytes/sec Asynchronous random reads: sectorsize: 7408 ops in 3.070315 sec = 2413 IOPS 4 kbytes: 6611 ops in 3.058482 sec = 2162 IOPS 32 kbytes: 4511 ops in 3.442903 sec = 1310 IOPS 128 kbytes: 3295 ops in 3.180279 sec = 1036 IOPS Шпиндельный диск: # diskinfo -i -c -t /dev/ada3 /dev/ada3 512 # sectorsize 2000398934016 # mediasize in bytes (1.8T) 3907029168 # mediasize in sectors 4096 # stripesize 0 # stripeoffset 3876021 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. TOSHIBA DT01ACA200 # Disk descr. 83EWYZ0KS # Disk ident. No # TRIM/UNMAP support 7200 # Rotation rate in RPM Not_Zoned # Zone Mode I/O command overhead: time to read 10MB block 0.820120 sec = 0.040 msec/sector time to read 20480 sectors 70.315131 sec = 3.433 msec/sector calculated command overhead = 3.393 msec/sector Seek times: Full stroke: 250 iter in 12.215429 sec = 48.862 msec Half stroke: 250 iter in 8.655560 sec = 34.622 msec Quarter stroke: 500 iter in 21.355126 sec = 42.710 msec Short forward: 400 iter in 15.620450 sec = 39.051 msec Short backward: 400 iter in 12.376752 sec = 30.942 msec Seq outer: 2048 iter in 8.641519 sec = 4.219 msec Seq inner: 2048 iter in 9.320166 sec = 4.551 msec Transfer rates: outside: 102400 kbytes in 13.106158 sec = 7813 kbytes/sec middle: 102400 kbytes in 13.921737 sec = 7355 kbytes/sec inside: 102400 kbytes in 23.852041 sec = 4293 kbytes/sec Asynchronous random reads: sectorsize: 515 ops in 3.979238 sec = 129 IOPS 4 kbytes: 475 ops in 4.062276 sec = 117 IOPS 32 kbytes: 468 ops in 4.099647 sec = 114 IOPS 128 kbytes: 425 ops in 4.470108 sec = 95 IOPS Bye, Eugene Grosbein, 11 янваpя 21

11 янв. 2021, понедельник, в 09:15 NOVT, Sergey Anohin написал(а): EG>> то innodb_log_write_ahead_size нужно делать равным блоку UFS2. EG>> Поэтому либо делай newfs -f 16386 под дефолтный блок 16K InnoDB, SA> То есть так сойдет: SA> newfs -f 16k -U -t /dev/ada2p2 SA> /dev/ada2p2: 60664.3MB (124240480 sectors) block size 32768, fragment size SA> 16384 Пардон, newfs -b 16k, а не newfs -f 16k. Eugene -- For the Colonel's Lady an' Judy O'Grady Are sisters under their skins!

Hello, Eugene! EG> Размер страницы InnoDB и размер блока UFS крайне желательно EG> иметь одинаковыми и изменить размер страницы однажды созданной базы InnoDB EG> нельзя, кроме как выгрузить все данные, пересоздать базу и загрузить EG> обратно. То же самое с UFS, так что размеры блоков нужно обдумать заранее. EG> Дефолтный размер блока UFS2 под FreeBSD нынче 32K (newfs -b). EG> Дефолтный размер страницы InnoDB (innodb_page_size) может зависеть EG> от версии базы, для MySQL 5.7 это 16K. А ещё в InnoDB есть EG> innodb_log_write_ahead_size, который не может превышать innodb_page_size, EG> но если ты всю требуху MySQL хранишь внутри /var/db/mysql на UFS2, Там пока zfs, на медленном диске, пока прибивать не буду сделаю локацию другую. Понапилено кастомизации: zroot/var/db 59,4G 1,34T 42,7G /var/db zroot/var/db/mysql 16,6G 1,34T 15,7G /var/db/mysql zroot/var/db/mysql/ibdata 657M 1,34T 657M /var/db/mysql/ibdata zroot/var/db/mysql/iblogs 328M 1,34T 328M /var/db/mysql/iblogs EG> то innodb_log_write_ahead_size нужно делать равным блоку UFS2. EG> Поэтому либо делай newfs -f 16386 под дефолтный блок 16K InnoDB, То есть так сойдет: newfs -f 16k -U -t /dev/ada2p2 /dev/ada2p2: 60664.3MB (124240480 sectors) block size 32768, fragment size 16384 EG> либо перед созданием базы в my.cnf пропиши innodb_page_size EG> и innodb_log_write_ahead_size равными блоку UFS2. EG> Это единственные вещи, которые сложно поменять потом, всё остальное EG> можно тюнить "на лету", если вдруг возникнет у тебя такая необходмость. EG> Может и не возникнуть. Ну проще ФС чем базу С наилучшими пожеланиями, Sergey Anohin.

09 янв. 2021, суббота, в 16:18 NOVT, Sergey Anohin написал(а): SA> А скажите как в 21 веке тюнят сабж? SA> Hашел только это: Размер страницы InnoDB и размер блока UFS крайне желательно иметь одинаковыми и изменить размер страницы однажды созданной базы InnoDB нельзя, кроме как выгрузить все данные, пересоздать базу и загрузить обратно. То же самое с UFS, так что размеры блоков нужно обдумать заранее. Дефолтный размер блока UFS2 под FreeBSD нынче 32K (newfs -b). Дефолтный размер страницы InnoDB (innodb_page_size) может зависеть от версии базы, для MySQL 5.7 это 16K. А ещё в InnoDB есть innodb_log_write_ahead_size, который не может превышать innodb_page_size, но если ты всю требуху MySQL хранишь внутри /var/db/mysql на UFS2, то innodb_log_write_ahead_size нужно делать равным блоку UFS2. Поэтому либо делай newfs -f 16386 под дефолтный блок 16K InnoDB, либо перед созданием базы в my.cnf пропиши innodb_page_size и innodb_log_write_ahead_size равными блоку UFS2. Это единственные вещи, которые сложно поменять потом, всё остальное можно тюнить "на лету", если вдруг возникнет у тебя такая необходмость. Может и не возникнуть. Eugene -- Господа Действительного Положения Вещей предохраняют себя от голода своим богатством, от общественного мнения - тайной и анонимностью, от частной критики - законами против клеветы и тем, что средства связи находятся в их распоряжении. (Hорберт Винер)

From: Alex Korchmar Sergey Anohin wrote: SA> Для фидо пойдет. для фидо пойдет пофиг как настроенное, что там от того фидо осталось-то? SA> У меня MariaDB, там веб-моpды база кpутится от фидо, хочу унести на SSD под SA> эхотагом. в размер страницы ты все равно не попадешь, поэтому пофигу чего ты там будешь делать. Бэкап делай. > Alex