|
Медленные коммиты транзакций в Linux
|
|||
---|---|---|---|
#18+
Есть программа, которая делает нехитрый OLTP — добавление/изменение пары записей в паре таблиц за транзакцию. Когда сервер работает под Windows (FB 2.5.8), коммит транзакции занимает 5-20 мс. Перенос БД на Linux (Ubuntu 18.04, FB 2.5.8 / 3.0.2) приводит к замедлению коммитов на порядок (50-200 мс), соответственно падает производительность ПО. Это можно как-то исправить настройкой сервера/ОС (не прибегая к gfix -write async)? Железо — офисный ПК, под базу выделен отдельный HDD. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 15:03 |
|
Медленные коммиты транзакций в Linux
|
|||
---|---|---|---|
#18+
Убрать барьер с файловой системы, перестать писать одно и то же дважды ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 15:07 |
|
Медленные коммиты транзакций в Linux
|
|||
---|---|---|---|
#18+
Смонтировал диск с nobarrier — производительность записи вернулась на место. Как я понимаю, в моём случае десктопного HDD такой режим работы будет приводить к необходимости ремонта БД после сбоя питания, тогда как включенный барьер избавил бы от неё? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 15:40 |
|
Медленные коммиты транзакций в Linux
|
|||
---|---|---|---|
#18+
Проверить не надёжнее и быстрее, чем спрашивать ? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 15:42 |
|
Медленные коммиты транзакций в Linux
|
|||
---|---|---|---|
#18+
RWolfнеобходимости ремонта БД после сбоя питания, тогда как включенный барьер избавил бы от неё натюрлих? включенный barrier спасает базу от повреждения? Базу от повреждения спасает хотя бы raid 1, плюс ups, плюс регулярные бэкапы. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 16:32 |
|
Медленные коммиты транзакций в Linux
|
|||
---|---|---|---|
#18+
RWolf, и еще я не понял. если на винде и линуксе одинаково, то зачем там линукс? Или наоборот. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 16:33 |
|
Медленные коммиты транзакций в Linux
|
|||
---|---|---|---|
#18+
kdv, если барьер не гарантирует целостности данных, тогда почему просто не включать gfix -write async по дефолту? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 16:41 |
|
Медленные коммиты транзакций в Linux
|
|||
---|---|---|---|
#18+
RWolf, в смысле? write sync (FW=ON) как раз более-менее гарантирует правильную последовательность записи страниц на диск, минимизируя возможные повреждения при ресете. FW=OFF, или write async, оставляет запись на волю операционной системы, из кэша которой страницы пишутся на диск как попало, в результате чего вероятность базы повредиться при ресете существенно возрастает. Опция barrier в линуксе - Write barriers enforce proper on-disk ordering of journal commits - не имеет никакого отношения к последовательности записи страниц Firebird-ом. И вообще, когда-то давно писали, что журналирование записи файловой системой нихрена не спасает от повреждений БД в случае всяких сбоев. Кстати, я 8 лет назад приводил данные по barrier: https://www.sql.ru/forum/895986/ext4-barrier-0-ili-1 ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 16:50 |
|
Медленные коммиты транзакций в Linux
|
|||
---|---|---|---|
#18+
kdvRWolf, и еще я не понял. если на винде и линуксе одинаково, то зачем там линукс? Или наоборот. Так изначально была поставлена задача — есть линуксовая машина, нужно перенести БД на неё. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 16:50 |
|
Медленные коммиты транзакций в Linux
|
|||
---|---|---|---|
#18+
kdvкогда-то давно писали, что журналирование записи файловой системой нихрена не спасает от повреждений БД в случае всяких сбоев. Более того, Лиля Козленко писала, что оно их провоцирует. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2019, 16:59 |
|
Медленные коммиты транзакций в Linux
|
|||
---|---|---|---|
#18+
kdv... Кстати, я 8 лет назад приводил данные по barrier: https://www.sql.ru/forum/895986/ext4-barrier-0-ili-1 kdvпросто фиксирую, для памяти. Fedora 16 with Kernel 3.1.1-1.fc16.x86_64 шедулеры cfq или deadline ...Дмитрий, возник вопрос - если диски поддерживают очереди команд и сами оптимизируют последовательность операций чтения/записи, зачем же зарубать фичу использованием шедулеров IO очередей? Почему не "no-op"? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.04.2019, 12:06 |
|
|
start [/forum/topic.php?fid=40&msg=39793660&tid=1560764]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
152ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
2ms |
others: | 15ms |
total: | 262ms |
0 / 0 |