|
|
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Всем привет. Народ подскажите, у меня высокая интенсивность запросов на вставку и обновление данных в БД Firebird 2.5 64-bit Classic и думаю установить режим Forced Writes у базы данных в OFF, прочитал, что это увеличит скорость операций записи до 3х раз. Кто нибудь пробовал отключать Forced Write? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2017, 11:23 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Sol87, ну если тебе плевать на сохранность БД можешь отключить. Если нет надо искать другие пути оптимизации ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2017, 11:27 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Sol87Кто нибудь пробовал отключать Forced Write?Да, пробовали так делать на паре филиалов, да работает заметно быстрее, насколько быстрее зависит от многих критериев. Да, в случае проблем с электричеством база рушится, и это тоже бывало. Но т.к. база филиальная,то она в принципе восстанавливается из центра, и, да восстанавливали. Нивелируется включением райтбэк кэширования на рэйд контроллере, это безопасно, но требуется соотв. оборудование. Поэтому общая рекомендация для тестовых БД и баз чисто хранимых агрегатов можно сделать асинхронную запись, для продакшн баз только синхронная запись и рэйд массив скорострельный, который может "пораскинуть своими мозгами" и писать отложенно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2017, 11:42 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Sol87Всем привет. Народ подскажите, у меня высокая интенсивность запросов на вставку и обновление данных в БД Firebird 2.5 64-bit Classic и думаю установить режим Forced Writes у базы данных в OFF, прочитал, что это увеличит скорость операций записи до 3х раз. Кто нибудь пробовал отключать Forced Write?Если сервер на ИБП с надлежащим обслуживанием, проблем быть не должно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2017, 11:51 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
rdb_dev, допустим стоит соответствующий ИБП, если я отключу Forced Writes, то измененные страницы находятся в кэше операционной системы до тех пор, пока операционная система не решит записать их на диск. Может же быть такое, что при непрерывной работе с БД операционная система может не сбрасывать измененные страницы на диск до тех пор, пока все пользователи не отсоединяться от базы данных. Каким то образом можно проконтролировать процесс записи на диск? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2017, 12:01 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Может быть что угодно. Проконтролировать нельзя. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2017, 12:08 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Вернее, повлиять можно (через конфиги MaxUnflushed*), но проконтролировать всё равно нельзя, AFAIU. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2017, 12:10 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Sol87Каким то образом можно проконтролировать процесс записи на диск?Зачем тебе это контролировать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2017, 12:14 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
rdb_dev, ну или можно настроить, чтобы данные записывались на диск в определенное время, или через какой то промежуток времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2017, 12:18 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Sol87> настроить, чтобы данные записывались на диск Sol87> в определенное время, или через какой то промежуток времени. Я как раз выше подсказал соотв. опции в конфиге. Можно настраивать время и/или количество. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2017, 12:24 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Sol87Всем привет. Народ подскажите, у меня высокая интенсивность запросов на вставку и обновление данных в БД Firebird 2.5 64-bit Classic и думаю установить режим Forced Writes у базы данных в OFF, прочитал, что это увеличит скорость операций записи до 3х раз. Кто нибудь пробовал отключать Forced Write? Лучше напиши, что за интенсивность (сколько запросов в минуту) и что за оборудование, какая дисковая подсистема. Каждый запрос в своей транзакции? или пачками? Параметры в запросах используются? и т.п. и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2017, 12:26 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам, sorry, не сразу увидел Вашу запись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2017, 12:29 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Sol87rdb_dev, ну или можно настроить, чтобы данные записывались на диск в определенное время, или через какой то промежуток времени.И что тебе это даст? Занафига эти пляски? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2017, 12:49 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
rdb_devЕсли сервер на ИБП с надлежащим обслуживанием, проблем быть не должно.Проблемы будут. Как вариант(было у нас): сервер работает, электричество тухнет, он какое-то время трудится, срабатывает автоматика, сервер получает команду по шнурику ИБП-Сервер и корректно гаснет. Появляется свет, но батареи еще не набрали полностью заряд, но сервер уже стартанул, свет снова тухнет и таймаута уже не хватает, чтобы погаснуть корректно. Привет кирдыкнутая база. Хочется гарантированного результата, то только синхронная запись на уровне файрберда, писать асинхронно можно "глубже" на уровне рэйда, там для этого предусмотрено все, что требуется для безопасной работы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2017, 13:43 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Ivan_Pisarevskyон какое-то время трудитсяВот это лишнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2017, 14:43 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Ivan_Pisarevskyrdb_devЕсли сервер на ИБП с надлежащим обслуживанием, проблем быть не должно.Проблемы будут. Как вариант(было у нас): сервер работает, электричество тухнет, он какое-то время трудится, срабатывает автоматика, сервер получает команду по шнурику ИБП-Сервер и корректно гаснет. Появляется свет, но батареи еще не набрали полностью заряд, но сервер уже стартанул, свет снова тухнет и таймаута уже не хватает, чтобы погаснуть корректно. Привет кирдыкнутая база.Ваш ИБП, скорее всего, был недонастроен. У меня даже на домашнем APC Smart-UPS SUA1000I есть настройка ИБП, задающая процент заряда батарей, при котором ИБП подает выходное напряжение при возобновлении входного напряжения. Доберусь до дома, могу глянуть подробней. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2017, 16:27 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
WildSeryIvan_Pisarevskyон какое-то время трудитсяВот это лишнее.Предлагаешь на каждое пропадание света на минуту тут же всех гасить? А работать когда? Свет у нас моргает регулярно и УПСы по рабочим местам не просто так, 9 из 10 таких морганий не приводят к остановкам в работе. rdb_devВаш ИБП, скорее всего, был недонастроен. У меня даже на домашнем APC Smart-UPS SUA1000I есть настройка ИБП, задающая процент заряда батарей, при котором ИБП подает выходное напряжение при возобновлении входного напряжения. Доберусь до дома, могу глянуть подробней.Это надо бы админа озадачить, не исключено, кстати. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2017, 17:32 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Ivan_Pisarevsky, Power Failure settings for APC Smart-UPS  Модератор: Вложение удалено. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2017, 19:04 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Sol87Всем привет. Народ подскажите, у меня высокая интенсивность запросов на вставку и обновление данных в БД Firebird 2.5 64-bit Classic и думаю установить режим Forced Writes у базы данных в OFF, прочитал, что это увеличит скорость операций записи до 3х раз. Кто нибудь пробовал отключать Forced Write? если сделать рейд из SSD, скорость увеличится во много больше раз, при меньшем риске. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2017, 22:53 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Ivan_PisarevskyПредлагаешь на каждое пропадание света на минуту тут же всех гасить? А работать когда? Свет у нас моргает регулярно и УПСы по рабочим местам не просто так, 9 из 10 таких морганий не приводят к остановкам в работе.Здесь считать надо, сколько держит ИБП всего, сколько времени занимает шатдаун/старт сервера, сколько времени занимает зарядка ИБП. Если время старт-стоп сервера относительно невелико, зарядка ИБП медленная, а свет тухнет часто, то да, через пару минут гасить. Поскольку 5 старт-стопов отнимут меньше времени, чем работа сервера на 10 минут дольше, но потом ожидание зарядки ИБП до приемлемого уровня. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2017, 09:52 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
NTFS To ensure that the right amount of flushing occurs, the cache manager spawns a process every second called a lazy writer. The lazy writer process queues one-eighth of the pages that have not been flushed recently to be written to disk. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2017, 10:47 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Siemargl, да пофиг. Этот lazy writer иногда застревал, и при крахе ОС у людей пропадало много чего. Тут ведь основная проблема в том, что при FW=ON ФБ пишет страницы на диск в определенном порядке. А при FW=OFF их пишет на диск ОС, в своем собственном порядке. Например, в базе распределяется новая страница. На нее пишутся данные, она привязывается к страницам таблицы. После чего страница помечается в PIP как используемая. То есть, примерно 3 страницы пишутся в базу в определенном порядке. Если в какой-то промежуточный момент нажать кнопку reset, то при FW=ON повреждений в базе не будет (например, orphan pages не считаются повреждением). А вот если FW=OFF, может произойти такое - в кэш ОС уехало 3 страницы - PP, DP, PIP. Первой записалась измененная PIP, потом PP. И тут нажали reset. Результат - страницы нет, а она помечена как используемая. В принципе, не катастрофа, но может быть и гораздо хуже. Однако, FW=ON все равно не является гарантией. Например, кэш дискового контроллера может иметь свои представления о том, в каком порядке что писать. А при сбоях SSD вообще ничего не поможет. Вот недавно в ремонт сообщили про базу в 25 гиг, в которой осталось только 7% полезной информации, остальное было занулено или испорчено. К сожалению, не знаю, был там raid из ssd, или нет, и вообще что произошло. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2017, 11:18 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
kdv, вообщем надо переходить на PostgreSQL) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2017, 11:12 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Sol87, для начала попробуй на Fb 3.0 SS перейти. В 3 раза конечно не увеличится, но прирост будет ощутимый. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2017, 11:15 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Sol87, Мы не против, переходи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2017, 11:15 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Симонов Денис, это через бэкап FB 2.5 и рестор 3.0 перенос ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2017, 11:26 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Sol87, да. Релиз ноты только прочти ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2017, 11:27 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Симонов Денис, а почему superserver? а не classic? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2017, 12:40 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Sol87, потому что SS в 3.0 быстрее классика ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2017, 12:41 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Sol87, потому что суперсервер 3.0 распараллеливается по ядрам. В результате необходимость в классике отпадает (не на 100%, конечно). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2017, 12:49 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
kdv, какие оптимальные настройки можно выставить? База данных размером 11 Гб, 40 ядер Xeon, 256GB RAM ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2017, 03:52 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Просьба не пинать за некромантию. Чот вспомнилось... kdvSiemargl, да пофиг. Этот lazy writer иногда застревал, и при крахе ОС у людей пропадало много чего. Тут ведь основная проблема в том, что при FW=ON ФБ пишет страницы на диск в определенном порядке. А при FW=OFF их пишет на диск ОС, в своем собственном порядке. Например, в базе распределяется новая страница. На нее пишутся данные, она привязывается к страницам таблицы. После чего страница помечается в PIP как используемая. То есть, примерно 3 страницы пишутся в базу в определенном порядке. Если в какой-то промежуточный момент нажать кнопку reset, то при FW=ON повреждений в базе не будет (например, orphan pages не считаются повреждением). А вот если FW=OFF, может произойти такое - в кэш ОС уехало 3 страницы - PP, DP, PIP. Первой записалась измененная PIP, потом PP. И тут нажали reset. Результат - страницы нет, а она помечена как используемая. В принципе, не катастрофа, но может быть и гораздо хуже.Если рассматривать кейс на SuperServer: FW=OFF и DefaultDbCachePages >= FileSystemCacheThreshold (использование файлового кэша системы подавлено) Как, в таком случае, будет вести себя запись? Будет ли соблюдаться правильный порядок записи страниц и как такая конфигурация скажется на производительности и устойчивости БД к повреждениям? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2019, 11:06 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
rdb_dev, такая конфигурация не гарантирует сброс кеша устройства. В общем случае, FW=ON тоже не всегда это гарантирует (зависит от интерфейса и контроллера), но система хотя бы пытается и обычно это получается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2019, 11:21 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
dimitrrdb_dev, такая конфигурация не гарантирует сброс кеша устройства.Это понятно. Но если не используется кэш файловой системы, то обеспечит ли кэш БД при FW=OFF правильный порядок скидывания страниц на носитель и, как следствие, исключение неустранимых сервером FirebirdSQL повреждений БД, если мы условимся, что наш носитель, к примеру - RAID контроллер с батарейкой или включенным WriteThrow? И получим ли мы существенный прирост производительности OLTP при интенсивных записях? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2019, 11:38 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
rdb_devоситель, к примеру - RAID контроллер с батарейкойвлияние асинхронного ВВ при этом устремляется к нулю. Смысл городить огород? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2019, 11:57 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Ivan_Pisarevskyrdb_devоситель, к примеру - RAID контроллер с батарейкойвлияние асинхронного ВВ при этом устремляется к нулю. Смысл городить огород?Ну ёлы-палы... Не о том вопрос! Меня интересует - обеспечивает ли кэш БД правильный порядок скидывания страниц на носитель? Почему асинхронный ввод/вывод стремиться к нулю, если при FW=OFF сервер пишет в кэш БД? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2019, 12:13 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
rdb_devНо если не используется кэш файловой системы, то обеспечит ли кэш БД при FW=OFF правильный порядок скидывания страниц на носительБД пишет страницы всегда в одном и том же правильном порядке. Сохраняется ли он нижележащими слоями - вопрос не к БД. rdb_devИ получим ли мы существенный прирост производительности OLTP при интенсивных записях?Зависит от диска. На SSD я получал выигрыш в TPCC порядка 15-20%, на HDD всё умрёт сразу же. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2019, 12:16 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
Ivan_Pisarevskyrdb_devноситель, к примеру - RAID контроллер с батарейкойвлияние асинхронного ВВ при этом устремляется к нулюНе понято ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2019, 12:17 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
rdb_devПочему асинхронный ввод/вывод стремиться к нулю, если при FW=OFF сервер пишет в кэш БД?Читайте правильно - не "асинхронный ввод/вывод стремится к нулю", а "влияние асинхронного ввода/вывода стремится к нулю". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2019, 12:20 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
rdb_devпри FW=OFF сервер пишет в кэш БДЧушь какая-то. На пальцах: сервер меняет содержимое страниц в своём кеше содержимое страничного кеша сохраняется на диск с помощью ОС ОС может кешировать файлы, а может и не кешировать движок по умолчанию даёт инструкцию кешировать файл БД (CachePages < FileSystemCacheThreshold) кроме того, ОС может кешировать метаданные файлов FW влияет на работу файлового кеша и кеша метаданных файловой системы. Нет способа отключить careful writes в Firebird. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2019, 12:23 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
hvladНа пальцах: сервер меняет содержимое страниц в своём кеше содержимое страничного кеша сохраняется на диск с помощью ОС ОС может кешировать файлы, а может и не кешировать движок по умолчанию даёт инструкцию кешировать файл БД (CachePages < FileSystemCacheThreshold) кроме того, ОС может кешировать метаданные файлов FW влияет на работу файлового кеша и кеша метаданных файловой системы. Нет способа отключить careful writes в Firebird.Повторюсь:rdb_devЕсли рассматривать кейс на SuperServer: FW=OFF и DefaultDbCachePages >= FileSystemCacheThreshold (использование файлового кэша системы подавлено) Как, в таком случае, будет вести себя запись? Будет ли соблюдаться правильный порядок записи страниц и как такая конфигурация скажется на производительности и устойчивости БД к повреждениям?Чуствую, либо меня не понимают, либо я чего-то не понимаю... Попробую перефразировать вопрос - как ведёт себя менеджер кэша БД при необходимости сбросить страницы на носитель (при вытеснении страниц на диск)? Соблюдает ли менеджер кэша тот же порядок записи страниц на носитель, в котором эти страницы были записаны сервером FirebirdSQL в кэш БД (не системный кэш файлов)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2019, 13:02 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
rdb_devкак ведёт себя менеджер кэша БД при необходимости сбросить страницы на носитель (при вытеснении страниц на диск)? в соответствии с политикой careful writes rdb_devСоблюдает ли менеджер кэша тот же порядок записи страниц на носитель, в котором эти страницы были записаны сервером FirebirdSQL в кэш БД (не системный кэш файлов)? нет никакого (значимого) "порядка записи в кеш БД", есть только "порядок записи из кеша БД на диск" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2019, 13:08 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
hvladкроме того, ОС может кешировать метаданные файлов FW влияет на работу файлового кеша и кеша метаданных файловой системы.Иными словами, если мы подавили использование файлового кэша (DefaultDbCachePages >= FileSystemCacheThreshold), то FW вообще никак не влияет? hvladНет способа отключить careful writes в Firebird.Это понятно! И хорошо, что нет такого способа. Правда, в случае использования FW=OFF и файлового кэша операционной системы, последнему наплевать на careful writes. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2019, 13:11 |
|
||
|
Forced Write = Off
|
|||
|---|---|---|---|
|
#18+
dimitrrdb_devкак ведёт себя менеджер кэша БД при необходимости сбросить страницы на носитель (при вытеснении страниц на диск)? в соответствии с политикой careful writes rdb_devСоблюдает ли менеджер кэша тот же порядок записи страниц на носитель, в котором эти страницы были записаны сервером FirebirdSQL в кэш БД (не системный кэш файлов)? нет никакого (значимого) "порядка записи в кеш БД", есть только "порядок записи из кеша БД на диск"Вот! Теперь мне понятно. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2019, 13:11 |
|
||
|
|
start [/forum/topic.php?all=1&fid=40&tid=1560651]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
52ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
70ms |
get tp. blocked users: |
1ms |
| others: | 11ms |
| total: | 176ms |
| 0 / 0 |
