|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
PgSQLAnonymousЕсли для выполнения запроса клиента СУБД нужно прочитать 100000 страниц, и в одном случае на это уходит 2 сек, а в другом 1, то похоже на то, что во втором случае IOPS вдвое больше (что может быть просто эффектом кэширования). ;) под IOPS, насколько я понимаю, принято считать количество блочных операций с дисковой энергонезависимой подсистемой? причем тут кэширование через оперативку? кэширование через SSD как часть файловой системы, например ZIL, еще можно рассматривать в контексте IOPS наглядно видно в db2top, есть physical reads и logical reads (из буферов), но writes ТОЛЬКО physical, потому что СУБД ожидает от файловой системы честные sync-и на каждый ее commit, хоть и страхуется через журнал, который желательно иметь в другой файловой системе конечно, можно выкрутить в ZFS sync-и в disabled, когда она все, что пока еще влазит, пишет только в оперативу, почти с таким же камикадзовским успехом можно использовать обычный RAM drive без сверхнадежного питания под часть базы кстати временное отключение sync ZFS почему-то мне не дало значительного прироста IOPS, может и потребности от приложения не было, поэтому? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 21:12 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
это все к тому, что IOPS увеличивается за счет количества шпинделей, а не за счет оперативки или сверхновых винтов с огромной скоростью последовательной записи, каждые несколько стареньких винтов в правильном массиве легко уделают каждый один новенький по IOPS ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 21:16 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
sanyock2кстати временное отключение sync ZFS почему-то мне не дало значительного прироста IOPS вернее прироста количества записываемых записей (или страниц в чем он там считает) в единицу времени по db2top ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 21:19 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
sanyock2PgSQLAnonymousЕсли для выполнения запроса клиента СУБД нужно прочитать 100000 страниц, и в одном случае на это уходит 2 сек, а в другом 1, то похоже на то, что во втором случае IOPS вдвое больше (что может быть просто эффектом кэширования). ;) под IOPS, насколько я понимаю, принято считать количество блочных операций с дисковой энергонезависимой подсистемой? причем тут кэширование через оперативку? Строго говоря — нипричём. Но упомянутому клиенту-то какая разница? ;) sanyock2кстати временное отключение sync ZFS почему-то мне не дало значительного прироста IOPS, может и потребности от приложения не было, поэтому? А может быть, потому, что sync реально не выполнялся и до этого? Вы проверяли? sanyock2это все к тому, что IOPS увеличивается за счет количества шпинделей, а не за счет оперативки или сверхновых винтов с огромной скоростью последовательной записи, каждые несколько стареньких винтов в правильном массиве легко уделают каждый один новенький по IOPS А на SSD как считать шпиндели? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 21:36 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
PgSQLAnonymoussanyock2кстати временное отключение sync ZFS почему-то мне не дало значительного прироста IOPS, может и потребности от приложения не было, поэтому? А может быть, потому, что sync реально не выполнялся и до этого? Вы проверяли? да куда бы он делся то в ZFS и "zfs get all | grep sync" того же мнения PgSQLAnonymoussanyock2это все к тому, что IOPS увеличивается за счет количества шпинделей, а не за счет оперативки или сверхновых винтов с огромной скоростью последовательной записи, каждые несколько стареньких винтов в правильном массиве легко уделают каждый один новенький по IOPS А на SSD как считать шпиндели? для начала надо понять, что такое есть шпиндель в обычном винте с точки зрения производительности для винтов IOPS по спекам обычно в районе 150-250, для простоты пусть будет 200 это значит, что головка его патифона может успевать не более 200 раз в секунду ерзать по поверхности его грампластинки в поисках места расположения очередного блока в SSD физика другая, IOPS в зависимости от навороченности может быть в сотни и тысячи раз больше винтов ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 21:55 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
Смешались в кучу кони, люди... ((с) Бородино) IOPsы, кэширование, SSD и т.п. в приложении к разным СУБД. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 22:32 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovДа нет проблем: две параллельные транзакции, впавшие в дэдлок, не могут быть закоммичены. Следовательно, они не могут привести БД в состояние, в которое они привели бы её, если бы выполнялись последовательно. Следовательно, такие транзакции - не serializable. Ну, во-первых, из двух транзакций, подпавших под дедлок, откатывается только одна. Во-вторых, ошибка в цепочке умозаключений. Из того, что у меня нет спичек, нельзя сделать абсолютно никаких вводов. Т.е. если не воспроизведены исходные условия (обе транзакции зафиксированы), делать выводы об их сериализуемости не представляется возможным. Т.е. ты опять всё поставил с ног на голову. Уровень изоляции не гарантирует обязательность выполнения (фиксации) транзакций. Он лишь определяет результат (состояние системы) после их фиксации. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 22:49 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
pkarklinУровень изоляции не гарантирует обязательность выполнения (фиксации) транзакций. Он лишь определяет результат (состояние системы) после их фиксации. А в чём разница? Если одна из транзакций не смогла зафиксироваться, значит заданный результат не достигнут и система не соответствует требованиям, предъявляемым к данному уровню. Короче: параллельное выполнение => операции одной транзакции не выполнились, последовательное выполнение => выполнились операции обоих транзакций. Разница налицо и, следовательно, данный уровень не соответствует стандарту на serializable как его описывает ПГанонимус. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 22:58 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, авторЕсли одна из транзакций не смогла зафиксироваться, значит заданный результат не достигнут и система не соответствует требованиям, предъявляемым к данному уровню. Необходимые и достаточные условия - это фиксирование обеих транзакций. Если этого не произошло - не выполнены исходные требования к системе. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 23:10 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
pkarklinНеобходимые и достаточные условия - это фиксирование обеих транзакций. Необходимое - да. Достаточное - нет. Одна транзакция делает update set f=f+3, вторая - update set f=f+4. Если обе транзакции закоммитились, а в результате поле увеличилось не на 7, то условие для serializable не выполнено. pkarklinЕсли этого не произошло - не выполнены исходные требования к системе. И таки да, как я уже сказал два раза: раз одна из транзакций не смогла закоммититься, значит система не выполняет условия для ношения гордого звания "поддерживает TIL serializable". Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 23:18 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, авторНеобходимое - да. Достаточное - нет. Одна транзакция делает update set f=f+3, вторая - update set f=f+4. Если обе транзакции закоммитились, а в результате поле увеличилось не на 7, то условие для serializable не выполнено. Нет, Дима, условия не такие... авторИ таки да, как я уже сказал два раза: раз одна из транзакций не смогла закоммититься , значит система не выполняет условия для ношения гордого звания "поддерживает TIL serializable". Ой, а тынц на стандарт ANSI можно? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 23:59 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
PgSQLAnonymoussanyock2кстати временное отключение sync ZFS почему-то мне не дало значительного прироста IOPS, может и потребности от приложения не было, поэтому? А может быть, потому, что sync реально не выполнялся и до этого? Вы проверяли? скорее всего потому что ZFS пишет sync-и сначала в ZIL (Intent Log) ПОСЛЕДОВАТЕЛЬНО, а у HDD при последовательном доступе пропускная способность по IOPS в сотни раз выше, чем при случайном http://storageioblog.com/part-ii-iops-hdd-hhdd-ssd/ нагрузка в десятки тысяч IOPs у меня очень редко бывает, поэтому наверно и разницы не было при "записи" sync-ов в RAM только странно то, что ZIL тогда был еще на общих винтах а не на отдельном SLOG device, в пуле ведь еще и случайные чтения точно были, хотя возможно спасал RAM cache для чтения ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2015, 10:51 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
sanyock2PgSQLAnonymousпропущено... А может быть, потому, что sync реально не выполнялся и до этого? Вы проверяли? да куда бы он делся то в ZFS и "zfs get all | grep sync" того же мнения А Вы джентельменам верите на слово? ;) Не имеет значения , что он там выдаёт. Вы тестировали , что Ваша дисковая система "на всём протяжении" (ФС, драйвер, RAID, диски) действительно делает fsync? Если частота fsync-ов при тестировнании превышает те IOPS-ы, которые у Вас должны быть, то, возможно, у меня для Вас плохие новости. ;) sanyock2скорее всего потому что ZFS пишет sync-и сначала в ZIL (Intent Log) ПОСЛЕДОВАТЕЛЬНО, Подождите, а что это значит? Она гарантирует , что при исчезновении питания все эти fsync-и будут выполнены при его восстановлении? Вот ссылка в тему: http://brad.livejournal.com/2116715.html ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2015, 13:47 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
pkarklinНет, Дима, условия не такие... По-моему, ему это всё равно. ;) pkarklinОй, а тынц на стандарт ANSI можно? Вряд ли он там это найдёт, потому что там написано следующее (подчёркивания мои): An SQL-transaction is terminated by a <commit statement> or a <rollback statement>. If an SQL-transaction is terminated by successful execution of a <commit statement>, then all changes made to SQL-data or schemas by that SQL-transaction are made persistent and accessible to all concurrent and subsequent SQL-transactions. If an SQL-transaction is terminated by a <rollback statement> or unsuccessful execution of a <commit statement>, then all changes made to SQL-data or schemas by that SQL-transaction are canceled. The execution of concurrent SQL-transactions at isolation level SERIALIZABLE is guaranteed to be serializable. A serializable execution is defined to be an execution of the operations of concurrently executing SQL-transactions that produces the same effect as some serial execution of those same SQL-transactions. A serial execution is one in which each SQL-transaction executes to completion before the next SQL-transaction begins. The execution of a <rollback statement> may be initiated implicitly by an SQL-implementation when it detects the inability to guarantee the serializability of two or more concurrent SQL-transactions. When this error occurs, an exception condition is raised: transaction rollback — serialization failure. Так вот ROLLBACK-и и DEADLOCK-и и есть "implicit rollback". Вот, кстати, соотвествующие стандарту SQLSTATE-ы PostgreSQL в этих случаях: Код: plaintext 1. 2. 3. 4. 5. 6.
... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2015, 14:04 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
PgSQLAnonymousThe execution of concurrent SQL-transactions at isolation level SERIALIZABLE is guaranteed to be serializable. PgSQLAnonymousThe execution of a <rollback statement> may be initiated implicitly by an SQL-implementation when it detects the inability to guarantee the serializability of two or more concurrent SQL-transactions. When this error occurs, an exception condition is raised: transaction rollback — serialization failure. Ты сам-то видишь противоречие этих двух заявлений? Или слова "уровень изоляции SERIALIZABLE гарантирует сериализацию " - пустой звук?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2015, 14:13 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
PgSQLAnonymoussanyock2пропущено... да куда бы он делся то в ZFS и "zfs get all | grep sync" того же мнения А Вы джентельменам верите на слово? ;) Не имеет значения , что он там выдаёт. Вы тестировали , что Ваша дисковая система "на всём протяжении" (ФС, драйвер, RAID, диски) действительно делает fsync? Если частота fsync-ов при тестировнании превышает те IOPS-ы, которые у Вас должны быть, то, возможно, у меня для Вас плохие новости. ;) у меня не тестовая лаборатория и я не тестер, чтобы тестировать commodity железки и софтины разве fsync не возвращает результат: успешно или нет, да и просто может находиться в состоянии ожидания? СУБД может сделать вывод о дальнейших действиях? кэш записи в контроллере отключен, диски проброшены как JBOD, ZFS - транзакционная файловая система, хорошо переживает hard reset, на старте обрабатывает журнал аналогично СУБД dstat показывает постоянную ежесекундную активность на запись - коммиты DB2, а не раз в 5 секунд как sync по умолчанию, даже и потеря транзакций за последние 5 секунд не так уже страшна в моем случае ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2015, 14:15 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovPgSQLAnonymousThe execution of concurrent SQL-transactions at isolation level SERIALIZABLE is guaranteed to be serializable. PgSQLAnonymousThe execution of a <rollback statement> may be initiated implicitly by an SQL-implementation when it detects the inability to guarantee the serializability of two or more concurrent SQL-transactions. When this error occurs, an exception condition is raised: transaction rollback — serialization failure. Ты сам-то видишь противоречие этих двух заявлений? Или слова "уровень изоляции SERIALIZABLE гарантирует сериализацию " - пустой звук?.. Нет, не вижу. И стандарт не видит. И разработчики большинства СУБД (я уже не уверен насчёт InterBase ;)) не видят. Как же так?! И вообще, как я уже говорил: PgSQLAnonymousПо-моему, ему это всё равно. ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2015, 14:29 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
PgSQLAnonymousИ разработчики большинства СУБД (я уже не уверен насчёт InterBase ;)) не видят. Как же так?! А так, что разработчики СУБД под названием "serializable" делают обычный "snapshot". Поскольку выполнить требование гарантировать сериализуемость не в силах. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2015, 15:02 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovЕщё раз: что в данном случае для Вас означает "блокируют"? Значит запрет на совершение определенного действия . Бывают блокировки на чтение , изменение , создание новых элементов, и т.д. Т.е. в случае версионника - может быть блокировка на создание новой версии, чтение промежуточного результата незафиксированной транзакции и т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2015, 12:48 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovПоскольку выполнить требование гарантировать сериализуемость не в силах. Да хватит уже спорить о том, что реальный мир отличается от идеального. Да в общем случае не всегда возможно найти ту последовательность действий, которая эквивалентна одновременному выполнению этих действий. Все что в этом случае может сделать реальная система - сказать: "упс! не могу". Как и в случае если у нее вдруг пропал доступ к подсистеме хранения, и по другим причинам. Но мы все понимаем, что реально последовательные системы доступа к данным можно сделать из любой БД с мало мальскими блокировками - только это нафиг никому не сдалось. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2015, 13:06 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
Сергей Арсеньев блокировка ... чтение промежуточного результата незафиксированной транзакции и т.д. нету у версионника такой блокировки. иначе нафиг он нужен. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2015, 10:40 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
kdv, Как бы пользуются люди Oracle, несмотря на то, что в нем очень затруднен режим dirty read. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2015, 13:37 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
Сергей АрсеньевКак бы пользуются люди Oracle, несмотря на то, что в нем очень затруднен режим dirty read. в InterBase и Firebird режима dirty read нет в принципе. Хотя, теоретически, его можно реализовать. Но в здравом уме разработчики это делать не собираются. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.05.2015, 00:03 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
[quot kdv]Сергей АрсеньевНо в здравом уме разработчики это делать не собираются. Напомнило: "Если в Oracle этого нет - значит это никому не нужно!" ... |
|||
:
Нравится:
Не нравится:
|
|||
23.05.2015, 00:57 |
|
|
start [/forum/topic.php?fid=35&msg=38963697&tid=1552327]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
44ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 162ms |
0 / 0 |