Firebird + журналируемая ФС

Администирование клиентской и серверной части InterBase, Firebird, Yaffil. Настройка файла конфигурации и т.п.

Модераторы: kdv, Alexey Kovyazin

Karp
Сообщения: 41
Зарегистрирован: 30 апр 2005, 16:30

Сообщение Karp » 24 авг 2006, 14:37

iSerge писал(а):Пока все что я нашел про FW - это утверждение что FW ON отключает кэш измененных страниц и таким образом все вносимые изменения БД сразу попадают на диск, а так же что включение этой опци приводит к серьезному падению производительности записи в БД.
а вот с этого места поподробнее - ну не видел я никогда и никакого "серьёзного" падения производительности при FW=ON

скорее уж тебе стоит озаботиться нормальной дисковой подсистемой.

И
iSerge писал(а):Увы, я пока не осознал, что то, о чем я говорю, это фигня.
осознать что то, о чём ты вопрошаешь - фигня :)

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 24 авг 2006, 14:56

Andrew Sagulin писал(а):В двух словах (как я понял): если между тем, как приложение запросило увеличение размера файла и получило Ok от WinAPI, и тем, как драйвер NTFS полностью зафиксировал изменения на диске, сделать Reset, то размер файла может не измениться, а все добавленные данные потеряются. При следующей загрузке СУБД "будет думать", что файл увеличился, а на самом деле это не так, и... "а пацаны-то не знают".
Не будет FB так думать, если FW=on - ссылок на потерянные страницы нигде не будет.

Вот простой пример:
Делаем insert, места в таблице нет, места в середине PIP нет
а) помечаем в последней PIP младший свободный бит (это номер страницы вне файла БД, сама PIP конечно внутри файла)
б) пишем в новую страницу данные
в) записываем номер новой страницы в PP таблицы

если сбой будет в момент
а) ничего не поломается, т.к. ссылок на новую страницу нигде нет и никто никогда не захочет её прочитать
б) аналогично, только страница будет помечена как занятая
в) аналогично
kdv писал(а):"Вот в системе есть АБЦ. А вы ее не используете. Ну почему, почему, почему? я сам не в курсе тонкостей АБЦ, но считаю эту штуку очень полезной - ведь зачем-то же ее сделали? а разработчики ваши, очевидно, среднего ума, раз не используют АБЦ"
Угу это я и хотел написать, только не сформулировал так корректно :wink:
iSerge писал(а):А кроме FW еще что-нибудь?
Читай про careful write и подумай о том, почему FW=OFF его херит

В MSDN нет (да и не может быть) API для "использования особенностей ЖФС".

iSerge
Сообщения: 10
Зарегистрирован: 23 авг 2006, 16:01

Сообщение iSerge » 24 авг 2006, 14:57

kdv писал(а):а разработчики ваши, очевидно, среднего ума, раз не используют АБЦ"
Нет, не так.
Если вопросом занимались, то где-то должно быть зафиксировано решение и причины почему оно принято. Или же если ответ всем очевиден, то, наверное, не сложно пояснить чайнику в чем суть.
Спасибо.

iSerge
Сообщения: 10
Зарегистрирован: 23 авг 2006, 16:01

Сообщение iSerge » 24 авг 2006, 14:58

Dimitry Sibiryakov писал(а): Точнее было бы сказать "выключение этой опции приводит к некоторому повышению производительности записи". На какой именно операции ты получил неустраивающую тебя производительность? И какой была это производительность?
Можно об этом где-нибудь почитать в подробностях?

iSerge
Сообщения: 10
Зарегистрирован: 23 авг 2006, 16:01

Сообщение iSerge » 24 авг 2006, 15:16

hvlad писал(а):Читай про careful write и подумай о том, почему FW=OFF его херит
Спасибо, это именно то ключевое слово, которого мне не хватало.

Merlin
Динозавр IB/FB
Сообщения: 1502
Зарегистрирован: 27 окт 2004, 11:44

Сообщение Merlin » 24 авг 2006, 15:41

iSerge писал(а): Пока все что я нашел про FW - это утверждение что FW ON отключает кэш измененных страниц и таким образом все вносимые изменения БД сразу попадают на диск,
И? Даже если не требовать от тебя уточнения о каком кеше речь - FB или оси. И закрыть глаза на невнятность формулировки "все вносимые изменения БД сразу".
iSerge писал(а): а так же что включение этой опци приводит к серьезному падению производительности записи в БД. Последнее меня не устраивает.
А ты у себя пробовал, со своими задачами и объёмами данных? Кстати, мне известны случаи, когда включение FW приводит к увеличению производительности ;)
iSerge писал(а): Поделитесь, пожалуйста, ссылочкой на материал где можно почитать поподробнее. Спасибо.
Учу пользоваться поиском. Дёшево. Заходим на www.ibase.ru, ищем глазками слева такую хрень, над которой написано Поиск, набираем там Forced Writes, жмакаем Ентер и чиатем по первым двум ссылкам, внимательно и до просветления. На здоровье.
iSerge писал(а): Увы, я пока не осознал, что то, о чем я говорю, это фигня.
Увы, никто, включая тебя самого, пока не осознал, о чём ты, собсно, говоришь.

Merlin
Динозавр IB/FB
Сообщения: 1502
Зарегистрирован: 27 окт 2004, 11:44

Сообщение Merlin » 24 авг 2006, 15:48

Кстати, о супернадёжности NTFS. Вчерась у нас за 10 минут всего лишь три раза свет вырубился. На станциях упсов нет, экономливые мы, лять. Мой диск пришлось снимать, цеплять к Алексу и гонять чекдиск - грузиться отказался.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 24 авг 2006, 16:35

Если вопросом занимались, то где-то должно быть зафиксировано решение и причины почему оно принято.
бюрократический ты наш. есть вопросы, которые не требуют консилиума, решений и их фиксаций.
Или же если ответ всем очевиден, то, наверное, не сложно пояснить чайнику в чем суть.
статья тебе прояснила суть?

суть вот такая - в NTFS журнал используется только для логических операций над файловой системой. Поэтому никакого смысла использовать эту штуку или как то прицеплять к СУБД нет. Поэтому этот вопрос нигде даже не рассматривался, потому что и рассматривать тут нечего.

p.s. топик получился на 70% откровенный флуд. но оставлю, для потомков.

Andrew Sagulin
Сообщения: 53
Зарегистрирован: 11 мар 2005, 15:44

Сообщение Andrew Sagulin » 24 авг 2006, 17:20

hvlad писал(а):Не будет FB так думать, если FW=on - ссылок на потерянные страницы нигде не будет.

Вот простой пример:
Делаем insert, места в таблице нет, места в середине PIP нет
а) помечаем в последней PIP младший свободный бит (это номер страницы вне файла БД, сама PIP конечно внутри файла)
б) пишем в новую страницу данные
в) записываем номер новой страницы в PP таблицы

Если после пункта "в" делается FlushFileBuffers, то да - потерь точно не будет. С другой стороны, может ли windows сделать сохранение на диске обновлённых страниц, в том числе и с изменённым PIP, но при этом не обновить метаданные файла? Если не может, т.е. метаданные таки обновляются, то FlushFileBuffers, скорее всего, в этом случае не обязателен.

BlackEric
Сообщения: 31
Зарегистрирован: 15 фев 2006, 08:43

Сообщение BlackEric » 06 сен 2006, 09:45

Dimitry Sibiryakov писал(а):Я так скажу: в свое время Лиля Козленко установила и доказала что размещение любой БД (она приводила Оракул в пример) на журналируемой ФС практически гарантирует ее порчу при сбое питания. Кроме того, это понижает ее быстродействие. Так что БД и ЖФС не дружат по определению.
Т.е. из этого следует, что базу под Виндой лучше размещать на FAT32, a не на NTFS, a под Linux ext2 предпочтительнее, чем ext3, xfs, reiserfs???:shock:
Я правильно понял :?:

А базу размером больше 4GB я на FAT32 то все равно не положу...

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 06 сен 2006, 10:02

из этого следует, что базу под Виндой лучше размещать на FAT32, a не на NTFS
нет, не следует.

Dimitry Sibiryakov
Заслуженный разработчик
Сообщения: 1436
Зарегистрирован: 15 сен 2005, 09:05

Сообщение Dimitry Sibiryakov » 06 сен 2006, 10:03

BlackEric писал(а):Т.е. из этого следует, что базу под Виндой лучше размещать на FAT32, a не на NTFS, a под Linux ext2 предпочтительнее, чем ext3, xfs, reiserfs??? :shock:
Я бы сказал - да, как и своп. Но иногда приходится поступаться быстродействием и надежностью ради безопасности. Про линуксовые системы ничего не могу сказать. Возможно, там журнализация не такая агрессивная и самопроизвольных откатов нет.
В любом случае это относится только к экстремальным серверам которые могут резко и жестко перезагрузиться.

Ответить