ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / auto sweep: должен ли он стартовать, если OST < OIT ?
72 сообщений из 72, показаны все 3 страниц
  все  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38691232
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hi all

Если есть вот это:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
         Oldest transaction      215825 
        Oldest active           215826
         Oldest snapshot         129653 
        Next transaction        248841
        Creation date           Jul 8, 2014 22:45:44
        Attributes

    Variable header data:
        Sweep interval:         1000

- то должен ли стартануть свип при таком маленьком интервальчике, как сейчас (1000) ?
В логе ФБ - пустошь, в трейсе тоже ничего.
...
Рейтинг: 0 / 0
08.07.2014, 23:50:00
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38691302
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Таблоид> В логе ФБ - пустошь

Ничего не путаешь? Версия, лог, сервер, файл?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
09.07.2014, 02:53:02
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38691360
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Гаджимурадов Рустам,

ничего не путаю.

$ /opt/fb30trnk/bin/fbsvcmgr localhost/3333:service_mgr user sysdba password masterke info_server_version info_svr_db_info
Server version: LI-T3.0.0.31208 Firebird 3.0 Alpha 2
Databases:
Number of attachments: 0
Number of databases: 0

В логе ФБ - ничего просвип нету.
Заголовок базы - см "фотку".
...
Рейтинг: 0 / 0
09.07.2014, 08:07:13
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38691380
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Насколько могу вспомнить, этот OST < OIT получился "как обычно": открыл в ИБЭ что-то (у него TIL = RC), забыл про него на 3-5 минут, а затем сделал rollback. При молотилках, работающих с TIL = snapshot, получаю этот самый застрявший OST.
...
Рейтинг: 0 / 0
09.07.2014, 08:34:10
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38691403
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ответь себе самому, какое отношение имеет OST к свипу. И заодно - как собирать мусор при таком OST.
...
Рейтинг: 0 / 0
09.07.2014, 08:57:45
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38691426
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrкакое отношение имеет OST к свипу. И заодно - как собирать мусор при таком OST.ну, я вот смотрю в garbage_collection.pdf (материалы "транзакционного семинара"), и там из написанного на стр. 27 делаю вывод: автозапуск свипа движком происходит, когда “sweep gap” : OST - OIT достигает лимита, либо дефолтного (20000), либо проставленного врукопашную.
...
Рейтинг: 0 / 0
09.07.2014, 09:19:45
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38691429
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrИ заодно - как собирать мусор при таком OST.еще бы понять, из-за чего такое вообще происходит (OST < OIT).
Вот запустил сейчас 40 окошек, и периодически дёргаю gstat -h. И каждый раз вижу, что OST отстаёт от OIT на 400-500. Т.е. все счетчики движутся "параллельно", но отставание OST от OIT - постоянно в этих пределах.
Коннекты не килял, все молотят свою работу.
...
Рейтинг: 0 / 0
09.07.2014, 09:24:10
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38691506
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ты пока можешь перечитать тынц раз и тынц два . А KDV с Владом пусть уже договорятся: OST - OIT или OAT - OIT :-) А то сколько лет уже разброд и метания.
...
Рейтинг: 0 / 0
09.07.2014, 10:16:51
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38691513
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоидну, я вот смотрю в garbage_collection.pdf (материалы "транзакционного семинара"), и там из написанного на стр. 27 делаю вывод: автозапуск свипа движком происходит, когда “sweep gap” : OST - OIT достигает лимита, либо дефолтного (20000), либо проставленного врукопашную.Ну так какие ещё вопросы ?
...
Рейтинг: 0 / 0
09.07.2014, 10:19:03
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38691782
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrты пока можешь перечитать тынц раз и тынц два . А KDV с Владом пусть уже договорятся: OST - OIT или OAT - OIT :-) А то сколько лет уже разброд и метания.
Почитал. http://www.ibase.ru/devinfo/sweep.htm в созданной базе данных есть параметр Sweep Interval, равный 20000. Как только разница между транзакциями Oldest Snapshot и Oldest (см. gstat -h db.gdb) (в InterBase 7.x и выше, и в Firebird 2.1 и выше - разница между Oldest Active и Oldest ) дQ1: про "ФБ 2.1 и выше" - это действительно так, т.е. сравнивается O A T ?
(и эта же фраза повторяется в тынц_два , только ФБ тут явно не упоминается: "Процесс сборки мусора (sweep) контролируется разницей между Oldest Interesting Transaction и Oldest Active Transaction (примечание kdv: в версиях InterBase ранее 7.1 данная разница считается между Oldest Interesting Transaction и Oldest Snapshot Transaction). ")

Мой случай, когда OST < OIT и OST < OAT, показан в тынц_два в таком виде:
kdvЕсли в базе данных не было большого rollback, но есть активная транзакция snapshot, то порядок будет:

OST -> OIT = OAT -> NTQ2: у меня стопудово ЕСТЬ большие роллбаки, которые невозможно сделать через отмены+коммит. И все активные транзакции работают в snapshot'e.
Застрявших транзакций нет, вот что вижу сейчас (через 4 часа после начала молотьбы):
Код: plaintext
1.
2.
3.
4.
5.
$ /opt/fb30trnk/bin/gstat -h oltp30.fdb | grep -i "oldest\|next tra"
        Oldest transaction      732500
        Oldest active           732501
        Oldest snapshot         730258
        Next transaction        734898
Ну так по какой причине OST всё время меньше OIT (хотя и движется вслед за ним) ? Свип из-за этого так и не стартует, и как тогда мусор убирать - каунтить таблицы периодически ?
...
Рейтинг: 0 / 0
09.07.2014, 12:44:06
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38691837
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидQ1: про "ФБ 2.1 и выше" - это действительно так, т.е. сравнивается O A T ?Нет, нет и ещё раз НЕТ.
Задолбало это уже.

ТаблоидНу так по какой причине OST всё время меньше OIT (хотя и движется вслед за ним) ?А какая вообще связь между OST и OIT ? С чего ты взял, что OST обязан быть больше OIT ?

В идеальном случае, когда нет роллбеков через TIP, OIT всегда будет равен OAT-1.
С чего ты взял, что OST должен быть равен OAT ??? Это возможно, только когда нет snapshot тр-ций.

ТаблоидСвип из-за этого так и не стартует, и как тогда мусор убирать - каунтить таблицы периодически ?Ты же был на семинаре, я же 100500 раз там акцентировал внимание на том, что эти счётчики НЕ ИМЕЮТ никакого отношения к кол-ву мусора в БД...

Ты статистику снимал ? На кол-во версий смотрел ? Оно только увеличивается ?
...
Рейтинг: 0 / 0
09.07.2014, 13:23:20
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38691839
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидQ2: у меня стопудово ЕСТЬ большие роллбаки, которые невозможно сделать через отмены+коммитТа ты шо ! И OIT у тебя не движется ? И свип не делается ? И стопудово роллбеки большие ? Ай-яй-яй...
...
Рейтинг: 0 / 0
09.07.2014, 13:24:22
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38691862
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladТаблоидQ2: у меня стопудово ЕСТЬ большие роллбаки, которые невозможно сделать через отмены+коммитТа ты шо ! И OIT у тебя не движется ? И свип не делается ? Ну я же говорю: OIT - движется. Они все вместе прут вверх, с почти постоянным интервалом OIT - OST =~500.
Но свип не стартует из-за отрицательной разницы OST - OIT, а в статистике некоторых таблиц - мусорная свалка. И мну она не нравится что-то... :-)
hvladИ стопудово роллбеки большие ? Ай-яй-яй...да, есть и большие (лок-обломы при отменах поднятых инвойсов, там тысячи строк меняются).
...
Рейтинг: 0 / 0
09.07.2014, 13:33:43
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38691868
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
hvladНет, нет и ещё раз НЕТ.
Задолбало это уже.
однако, KDV - саботажник...
...
Рейтинг: 0 / 0
09.07.2014, 13:36:07
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38691872
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидда, есть и большие
тогда бы OIT застыл намертво (до свипа)
...
Рейтинг: 0 / 0
09.07.2014, 13:37:35
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38691873
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladТаблоидQ1: про "ФБ 2.1 и выше" - это действительно так, т.е. сравнивается O A T ?Нет, нет и ещё раз НЕТ.
Задолбало это уже. 2 kdv : ну поправь доку уже, что ле...
hvladТаблоидНу так по какой причине OST всё время меньше OIT (хотя и движется вслед за ним) ?А какая вообще связь между OST и OIT ? С чего ты взял, что OST обязан быть больше OIT ?в бол-ве продакшен-систем - как они соотносятся ? что-то встряло в голову, что OIT обычно меньше OST.
hvladВ идеальном случае, когда нет роллбеков через TIP, OIT всегда будет равен OAT-1.
С чего ты взял, что OST должен быть равен OAT ??? Это возможно, только когда нет snapshot тр-ций.не, я как раз OST и не сравнивал с OAT. Просто привёл цитату с ibase.ru, там соотношение показано между ними.

hvladТаблоидСвип из-за этого так и не стартует, и как тогда мусор убирать - каунтить таблицы периодически ?Ты же был на семинаре, я же 100500 раз там акцентировал внимание на том, что эти счётчики НЕ ИМЕЮТ никакого отношения к кол-ву мусора в БД...

Ты статистику снимал ? На кол-во версий смотрел ? Оно только увеличивается ?Статистику снимал, но не логировал, к сож-ю. И не по всем таблицам.
Сегодня запущу задание в кроне, пущай откладывает.
...
Рейтинг: 0 / 0
09.07.2014, 13:38:08
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38691879
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrТаблоидда, есть и большиетогда бы OIT застыл намертво (до свипа)Тогда, если они не большие, я должен был бы видеть в трейсе по каждому роллбаку (для транзакций, которые действительно что-то меняли) статистику его действий по таблицам - так или нет ?
...
Рейтинг: 0 / 0
09.07.2014, 13:40:20
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38691892
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
dimitrоднако, KDV - саботажник...
Таблоид2 kdv: ну поправь доку уже, что ле...
в где поправить?

единственные ссылки на то, что sweep interval срабатывает при OAT-OIT, есть только в отношении InterBase, якобы в какой то версии (типа 7.1) поменяли срабатывание с OST-OIT на OAT-OIT. И все.
...
Рейтинг: 0 / 0
09.07.2014, 13:47:26
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38691896
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид,

ты сначала выясни, у тебя OIT сам по себе не отстает (тогда больших роллбеков нет) или это твой автосвип его постоянно подгоняет (и тогда они есть)
...
Рейтинг: 0 / 0
09.07.2014, 13:48:44
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38691897
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Таблоид, dimitr

все, извиняюсь, нашел, исправил. Вообще надо бы и InterBase проверить, а то вдруг меня жестоко обманули.
...
Рейтинг: 0 / 0
09.07.2014, 13:49:37
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38692030
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Таблоид,

твоя картинка (когда OST отстает от OIT) рассказывается тут
"Когда ReadCommitted блокирует Oldest Snapshot"
http://www.ibase.ru/devinfo/summary.htm
и то же самое есть в последней презентации AK на семинаре по транзакциям.

Если у тебя были "настоящие роллбэки", то из-за мелкого sweep interval ты скорее всего проглядел авто-запуск sweep. В логе точно свипа нет?
...
Рейтинг: 0 / 0
09.07.2014, 15:13:46
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38692052
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
dimitrты сначала выясни, у тебя OIT сам по себе не отстает (тогда больших роллбеков
нет) или это твой автосвип его постоянно подгоняет (и тогда они есть)
А кстати: у IBS или IBE нет (случайно так) тулзы, которая бы показывала состояние
транзакций в TIP? Хотя, конечно, получив голую TIP можно и глазками посмотреть...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
09.07.2014, 15:28:36
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38692126
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvтвоя картинка (когда OST отстает от OIT) рассказывается тут
"Когда ReadCommitted блокирует Oldest Snapshot"
http://www.ibase.ru/devinfo/summary.htm
и то же самое есть в последней презентации AK на семинаре по транзакциям.kdv, спасибо! есть у мну одна догадка: это служебная ХП, которая регулярно стартует с TIL = RC и выполняет пересчет статистики индексов. Я её затолкал в RC... не помню уже, для чего :-)
Других аттачей с TIL = RC нету, так что сейчас переделаю эту штуку.

kdvЕсли у тебя были "настоящие роллбэки", то из-за мелкого sweep interval ты скорее всего проглядел авто-запуск sweep. В логе точно свипа нет?Точно нету.
...
Рейтинг: 0 / 0
09.07.2014, 16:09:46
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38692146
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladТы статистику снимал ? На кол-во версий смотрел ? Оно только увеличивается ?Запустил 50 молотилок, работают почти 2 часа.
Запустил также два .sh-скрипта, которые с интервалом 10 сек делают:
1) gstat -h с фильтром значений счетчиков
2) gstat -r с фильтром значений версий в тех таблицах, что мну сильнее всего сейчас интересуют (т.к. они меняются самым интенсивным образом).

Результат:
1) число версий в таблицах сначала выросло до нек. значений, а затем стало "танцевать" вокруг них, с небольшими амлитудами. Но постоянного роста - нету;
2) счетчики стабильно прут вверх, но и интервал OST - OIT также стабилен.

Логи в аттаче.
...
Рейтинг: 0 / 0
09.07.2014, 16:26:44
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38692237
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
http://www.ibase.ru/devinfo/summary.htm Обратите внимание, что Oldest transaction больше Oldest snapshot. И Sweep gap имеет отрицательное значение. Это может произойти в двух случаях.
Первый случай , когда есть периодически стартуемые и завершаемые транзакции snapshot. То есть, эта картинка показывает наличие "долгоживущих" snapshot так же, как и предыдущая.
Второй случай происходит на серверах, кроме IB 7.1, при работе с ReadCommitted транзакциями (или в комбинации read_committed и snapshot). Здесь транзакция ReadCommitted блокирует Oldest Snapshot точно таким же образом, как транзакции Snapshot.Переделал процедуру, собиравшую статистику по индексам в RC, под снапшот.
Теперь ReadCommitted транзакций нет. Вообще.

Увы и ах, но по прежнему OST < OIT, причём опять на какую-то стабильную величину около 500:
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
20140709_174224 iter 82
......................
        Oldest transaction      48834
        Oldest active           48835
        Oldest snapshot         48304
        Next transaction        49326
now sleep 10 seconds. . .

20140709_174234 iter 83
......................
        Oldest transaction      49213
        Oldest active           49214
        Oldest snapshot         48691
        Next transaction        49832
now sleep 10 seconds. . .

20140709_174244 iter 84
......................
        Oldest transaction      49791
        Oldest active           49792
        Oldest snapshot         49214
        Next transaction        50434
now sleep 10 seconds. . .

20140709_174254 iter 85
......................
        Oldest transaction      50472
        Oldest active           50473
        Oldest snapshot         49872
        Next transaction        51095
now sleep 10 seconds. . .
Остается тогда только первый случай - наличие долгих снапшотов.
Значит, автосвип так и не будет стартовать.
Утешает, впрочем, что число версий не растёт после того, как достигнет некоторого потолка.

ЗЫ. Пока не появится фича, позволяющая разобраться в причинах сумасшедших значений времени при небольших числах fetches / marks и практически отсутствующих reads/writes - причину застреваний не найти :(
...
Рейтинг: 0 / 0
09.07.2014, 17:44:19
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38692254
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Таблоид> ЗЫ. Пока не появится фича, позволяющая разобраться
Таблоид> в причинах сумасшедших значений времени при
Таблоид> небольших числах fetches / marks и практически
Таблоид> отсутствующих reads/writes - причину застреваний не найти :(

Какое это имеет отношение к застреванию OST, мусору и свипу?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
09.07.2014, 18:05:13
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38692307
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Гаджимурадов РустамТаблоид> ЗЫ. Пока не появится фича, позволяющая разобраться
Таблоид> в причинах сумасшедших значений времени при
Таблоид> небольших числах fetches / marks и практически
Таблоид> отсутствующих reads/writes - причину застреваний не найти :(

Какое это имеет отношение к застреванию OST, мусору и свипу?
Накопление мусора к произв-сти разве не имеет отношения ?
Впрочем, он у мну, как внезапно выяснилось, почти накапливается. Так что может, ты и прав - никакого :-)
...
Рейтинг: 0 / 0
09.07.2014, 18:54:24
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38692345
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидТеперь ReadCommitted транзакций нет. Вообще.

Увы и ах, но по прежнему OST < OITА с чего ты взял, что должно быть иначе, и что избавление от RC тебе в этом как-то поможет ?
...
Рейтинг: 0 / 0
09.07.2014, 19:58:09
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38692361
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladА с чего ты взял, что должно быть иначе, и что избавление от RC тебе в этом как-то поможет ?ну потому что во:kdv http://www.ibase.ru/devinfo/summary.htm
Обратите внимание, что Oldest transaction больше Oldest snapshot . И Sweep gap имеет отрицательное значение. Это может произойти в двух случаях.
Первый случай, когда есть периодически стартуемые и завершаемые транзакции snapshot. То есть, эта картинка показывает наличие "долгоживущих" snapshot так же, как и предыдущая.
Второй случай происходит на серверах, кроме IB 7.1, при работе с ReadCommitted транзакциями (или в комбинации read_committed и snapshot). Здесь транзакция ReadCommitted блокирует Oldest Snapshot точно таким же образом, как транзакции Snapshot.
...
Рейтинг: 0 / 0
09.07.2014, 20:30:30
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38692370
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоид,

т.е. ты свёл (некорректно описанный) второй случай к первому (избавившись от RC), и... что ?

Говорили же на семинаре, что поток RC тр-ций двигает OST быстрее, чем аналогичный поток Snapshot тр-ций. Картинки рисовали. Разжевали и в рот положили, не ?
Как можно после этого писать эту ахинею, я не понимаю...
...
Рейтинг: 0 / 0
09.07.2014, 20:39:49
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38692393
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladт.е. ты свёл (некорректно описанный) второй случай к первому (избавившись от RC), и... что ?что на некорректно описано, поясни, плз.
hvladГоворили же на семинаре, что поток RC тр-ций двигает OST быстрее, чем аналогичный поток Snapshot тр-ций. Картинки рисовали. Разжевали и в рот положили, не ?Вот смотрю я в pdf-ники - и НЕ вижу. В упор. В где там про это сказано ?
...
Рейтинг: 0 / 0
09.07.2014, 21:35:03
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38692395
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladт.е. ты свёл (некорректно описанный) второй случай к первому (избавившись от RC), и... что ?почему это "свёл второй случай к первому" ? я просто методом исключения действовал :-)
Убрал к ЧМ последний вариант, где стартовала RC (а она часто стартовала, т.к. пересчет статистики мну необходим в этом тесте как вода в пустыне). Не помогло. Вот и остался только первый случай :-)
...
Рейтинг: 0 / 0
09.07.2014, 21:37:08
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38692465
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоидhvladт.е. ты свёл (некорректно описанный) второй случай к первому (избавившись от RC), и... что ?что на некорректно описано, поясни, плз.То, что
kdvтранзакция ReadCommitted блокирует Oldest Snapshot точно таким же образом, как транзакции Snapshot.От этого избавились ещё в FB 2.0

И ты вообще всё там понял наоборот: там говорится о том, что OST может быть меньше OIT при потоке
1. snapshot тр-ций
2. read committed тр-ций до IB 7.1 и во всех FB (на самом деле и в FB 2.0 это тоже уже не так)

Ты же почему-то решил, что превратив RC в snapshot у тебя OST станет двигаться быстрее.
Что есть бред, извини

ТаблоидhvladГоворили же на семинаре, что поток RC тр-ций двигает OST быстрее, чем аналогичный поток Snapshot тр-ций. Картинки рисовали. Разжевали и в рот положили, не ?Вот смотрю я в pdf-ники - и НЕ вижу. В упор. В где там про это сказано ?"Внутреннее устройство транзакций в Firebird", стр 19
...
Рейтинг: 0 / 0
09.07.2014, 23:02:27
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38692589
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Таблоид, hvlad
в статье написано:
примечание: данное поведение в отношении read_committed исправлено в Firebird 2.0.
...
Рейтинг: 0 / 0
10.07.2014, 02:41:32
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38692755
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladТаблоидпропущено...Вот смотрю я в pdf-ники - и НЕ вижу. В упор. В где там про это сказано ?"Внутреннее устройство транзакций в Firebird", стр 19Увидел, спс.
Ну, значит не взлетит у мну этот автосвип, ибо в тесте этом всё должно работать в снапшотах.
Вчера в 21:20 запустил 200 молотилок, сейчас смотрю в лог - свипа не было.
OST быстро стал на несколько сотен меньше чем OIT, далее счетчики лезут вверх, но всё время при этом OST < OIT. Кол-во версий в таблицах сильно колеблется, то 20 тыс, то 300 тыс - но всё общего тренда их увеличения вроде бы нет.
...
Рейтинг: 0 / 0
10.07.2014, 10:19:45
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38692867
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
kdvТаблоид, hvlad
в статье написано:
примечание: данное поведение в отношении read_committed исправлено в Firebird 2.0. Звучит как отмазка :)

 
PS Как по мне, надо бы давно уже пересмотреть древние статьи и привести их к нынешним реалиям.
Не думаю, что кому-то (кроме археологов) интересно как оно себя вело 10 лет назад.
Для тех, кому всё же интересно - можно оставить оригиналы статей рядом с современными вариантами.
...
Рейтинг: 0 / 0
10.07.2014, 11:30:00
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38692871
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоидзначит не взлетит у мну этот автосвипНе нужен он тебе
...
Рейтинг: 0 / 0
10.07.2014, 11:30:45
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38693044
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
hvladЗвучит как отмазка :)
пусть Таблоид свой тест на голом RC проверит, и посмотрим, уезжает у него OIT выше OST, или нет. А тогда уже будем решать, исправлять, или нет :-)
...
Рейтинг: 0 / 0
10.07.2014, 12:52:04
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38693098
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
kdvтогда уже будем решать, исправлять, или нет :-)Неожиданно
...
Рейтинг: 0 / 0
10.07.2014, 13:22:16
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38693099
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladНе нужен он тебеПочему ? как ты это понял ?
Вот, например, текущие данные по 5 самым меняемым таблицам:
 
QDISTR recs=732'065, vers=209'512, swept pages=26'405
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
QDISTR (151)
    Primary pointer page: 239, Index root page: 240
    Total formats: 1, used formats: 1
    Average record length: 67.92, total records: 7320652
    Average version length: 44.06, total versions: 209512, max versions: 4
    Average fragment length: 56.00, total fragments: 1, max fragments: 1
    Average unpacked length: 128.00, compression ratio: 1.88
    Pointer pages: 14, data page slots: 50785
    Data pages: 50785, average fill: 77%
    Primary pages: 50471, full pages: 48640, swept pages: 26405
    Fill distribution:
	 0 - 19% = 302
	20 - 39% = 26
	40 - 59% = 114
	60 - 79% = 47499
	80 - 99% = 2844

    Index PK_QDISTR (0)
	Root page: 26566, depth: 3, leaf buckets: 7180, nodes: 7320730
	Average node length: 11.29, total dup: 3219, max dup: 3
	Average key length: 8.30, compression ratio: 1.08
	Average prefix length: 3.70, average data length: 5.30
	Clustering factor: 865562, ratio: 0.12
	Fill distribution:
	     0 - 19% = 70
	    20 - 39% = 784
	    40 - 59% = 1585
	    60 - 79% = 1422
	    80 - 99% = 3319

    Index QDISTR_DOC_SND (3)
	Root page: 17716, depth: 3, leaf buckets: 6179, nodes: 7320730
	Average node length: 6.21, total dup: 6572863, max dup: 79
	Average key length: 3.22, compression ratio: 8.38
	Average prefix length: 25.88, average data length: 1.12
	Clustering factor: 455955, ratio: 0.06
	Fill distribution:
	     0 - 19% = 44
	    20 - 39% = 1862
	    40 - 59% = 3560
	    60 - 79% = 580
	    80 - 99% = 133

    Index QDISTR_SNDOP_RCVOP_SND_ID_DESC (4)
	Root page: 28518, depth: 3, leaf buckets: 6345, nodes: 7330977
	Average node length: 6.48, total dup: 6073767, max dup: 121
	Average key length: 3.49, compression ratio: 11.98
	Average prefix length: 40.46, average data length: 1.32
	Clustering factor: 735141, ratio: 0.10
	Fill distribution:
	     0 - 19% = 1
	    20 - 39% = 881
	    40 - 59% = 5383
	    60 - 79% = 57
	    80 - 99% = 23

    Index QDISTR_SND_ID (2)
	Root page: 44655, depth: 3, leaf buckets: 4847, nodes: 7320739
	Average node length: 5.69, total dup: 6572870, max dup: 79
	Average key length: 2.70, compression ratio: 3.34
	Average prefix length: 8.41, average data length: 0.59
	Clustering factor: 476028, ratio: 0.07
	Fill distribution:
	     0 - 19% = 134
	    20 - 39% = 1010
	    40 - 59% = 2299
	    60 - 79% = 582
	    80 - 99% = 822

    Index QDISTR_WARE_SND_OPTYPE (1)
	Root page: 39882, depth: 3, leaf buckets: 3968, nodes: 7330997
	Average node length: 5.01, total dup: 7328997, max dup: 17735
	Average key length: 2.02, compression ratio: 13.38
	Average prefix length: 26.98, average data length: 0.02
	Clustering factor: 994637, ratio: 0.14
	Fill distribution:
	     0 - 19% = 10
	    20 - 39% = 3
	    40 - 59% = 3167
	    60 - 79% = 575
	    80 - 99% = 213
 
QSTORNED recs=3'171'071, vers=203'193, swept pages=12'502
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
QSTORNED (152)
    Primary pointer page: 241, Index root page: 242
    Total formats: 1, used formats: 1
    Average record length: 70.92, total records: 3171071
    Average version length: 40.97, total versions: 203193, max versions: 2
    Average fragment length: 34.73, total fragments: 88, max fragments: 1
    Average unpacked length: 128.00, compression ratio: 1.80
    Pointer pages: 7, data page slots: 23382
    Data pages: 23382, average fill: 76%
    Primary pages: 23347, full pages: 18731, swept pages: 12502
    Fill distribution:
	 0 - 19% = 133
	20 - 39% = 373
	40 - 59% = 1136
	60 - 79% = 11989
	80 - 99% = 9751

    Index PK_QDSTORNED (0)
	Root page: 30051, depth: 3, leaf buckets: 3521, nodes: 3171071
	Average node length: 11.66, total dup: 29890, max dup: 4
	Average key length: 8.68, compression ratio: 1.04
	Average prefix length: 3.31, average data length: 5.69
	Clustering factor: 1009589, ratio: 0.32
	Fill distribution:
	     0 - 19% = 5
	    20 - 39% = 66
	    40 - 59% = 1508
	    60 - 79% = 1321
	    80 - 99% = 621

    Index QSTORNED_DOC_ID (1)
	Root page: 72001, depth: 3, leaf buckets: 1569, nodes: 3171071
	Average node length: 5.21, total dup: 3070332, max dup: 1521
	Average key length: 2.23, compression ratio: 4.03
	Average prefix length: 8.80, average data length: 0.20
	Clustering factor: 568483, ratio: 0.18
	Fill distribution:
	     0 - 19% = 0
	    20 - 39% = 29
	    40 - 59% = 630
	    60 - 79% = 608
	    80 - 99% = 302

    Index QSTORNED_RCV_ID (3)
	Root page: 54565, depth: 3, leaf buckets: 2269, nodes: 3171083
	Average node length: 5.30, total dup: 2980452, max dup: 343325
	Average key length: 2.32, compression ratio: 3.46
	Average prefix length: 7.65, average data length: 0.37
	Clustering factor: 138360, ratio: 0.04
	Fill distribution:
	     0 - 19% = 66
	    20 - 39% = 933
	    40 - 59% = 805
	    60 - 79% = 285
	    80 - 99% = 180

    Index QSTORNED_SND_ID (2)
	Root page: 67458, depth: 3, leaf buckets: 1752, nodes: 3171069
	Average node length: 5.77, total dup: 2815158, max dup: 99
	Average key length: 2.80, compression ratio: 3.22
	Average prefix length: 8.32, average data length: 0.68
	Clustering factor: 633657, ratio: 0.20
	Fill distribution:
	     0 - 19% = 1
	    20 - 39% = 22
	    40 - 59% = 758
	    60 - 79% = 662
	    80 - 99% = 309
 
PDISTR recs=74'206, vers=78'525, swept pages=30
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
PDISTR (153)
    Primary pointer page: 243, Index root page: 244
    Total formats: 1, used formats: 1
    Average record length: 17.30, total records: 74206
    Average version length: 29.52, total versions: 78525, max versions: 12
    Average fragment length: 0.00, total fragments: 0, max fragments: 0
    Average unpacked length: 64.00, compression ratio: 3.70
    Pointer pages: 1, data page slots: 875
    Data pages: 587, average fill: 66%
    Primary pages: 453, full pages: 383, swept pages: 30
    Fill distribution:
	 0 - 19% = 129
	20 - 39% = 56
	40 - 59% = 9
	60 - 79% = 49
	80 - 99% = 344

    Index PDISTR_AGENT_ID (1)
	Root page: 3249, depth: 2, leaf buckets: 32, nodes: 74206
	Average node length: 4.30, total dup: 74155, max dup: 9411
	Average key length: 2.01, compression ratio: 4.48
	Average prefix length: 8.99, average data length: 0.01
	Clustering factor: 4502, ratio: 0.06
	Fill distribution:
	     0 - 19% = 0
	    20 - 39% = 1
	    40 - 59% = 15
	    60 - 79% = 11
	    80 - 99% = 5

    Index PDISTR_ID_DESC (3)
	Root page: 901, depth: 2, leaf buckets: 102, nodes: 74206
	Average node length: 11.12, total dup: 0, max dup: 0
	Average key length: 8.84, compression ratio: 1.02
	Average prefix length: 3.16, average data length: 5.84
	Clustering factor: 1207, ratio: 0.02
	Fill distribution:
	     0 - 19% = 0
	    20 - 39% = 10
	    40 - 59% = 85
	    60 - 79% = 6
	    80 - 99% = 1

    Index PDISTR_SND_ID (2)
	Root page: 2173, depth: 2, leaf buckets: 44, nodes: 74206
	Average node length: 5.21, total dup: 64982, max dup: 21
	Average key length: 2.93, compression ratio: 3.08
	Average prefix length: 8.20, average data length: 0.80
	Clustering factor: 6167, ratio: 0.08
	Fill distribution:
	     0 - 19% = 0
	    20 - 39% = 5
	    40 - 59% = 27
	    60 - 79% = 9
	    80 - 99% = 3

    Index PK_PDISTR (0)
	Root page: 899, depth: 2, leaf buckets: 92, nodes: 74206
	Average node length: 11.12, total dup: 0, max dup: 0
	Average key length: 8.83, compression ratio: 1.02
	Average prefix length: 3.16, average data length: 5.84
	Clustering factor: 1207, ratio: 0.02
	Fill distribution:
	     0 - 19% = 19
	    20 - 39% = 24
	    40 - 59% = 10
	    60 - 79% = 3
	    80 - 99% = 36
 
PSTORNED recs=552'691, vers=52'624, swept pages=960
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
PSTORNED (154)
    Primary pointer page: 245, Index root page: 246
    Total formats: 1, used formats: 1
    Average record length: 51.10, total records: 552691
    Average version length: 31.55, total versions: 52624, max versions: 2
    Average fragment length: 45.67, total fragments: 6, max fragments: 1
    Average unpacked length: 80.00, compression ratio: 1.57
    Pointer pages: 1, data page slots: 3273
    Data pages: 3273, average fill: 75%
    Primary pages: 3263, full pages: 2734, swept pages: 960
    Fill distribution:
	 0 - 19% = 6
	20 - 39% = 4
	40 - 59% = 70
	60 - 79% = 2844
	80 - 99% = 349

    Index PK_PSTORNED (0)
	Root page: 1047, depth: 2, leaf buckets: 616, nodes: 552691
	Average node length: 11.88, total dup: 0, max dup: 0
	Average key length: 9.05, compression ratio: 0.99
	Average prefix length: 2.95, average data length: 6.05
	Clustering factor: 17575, ratio: 0.03
	Fill distribution:
	     0 - 19% = 1
	    20 - 39% = 47
	    40 - 59% = 192
	    60 - 79% = 240
	    80 - 99% = 136

    Index PSTORNED_RCV_ID (2)
	Root page: 1259, depth: 2, leaf buckets: 371, nodes: 552691
	Average node length: 5.64, total dup: 491877, max dup: 922
	Average key length: 2.81, compression ratio: 3.21
	Average prefix length: 8.30, average data length: 0.70
	Clustering factor: 51071, ratio: 0.09
	Fill distribution:
	     0 - 19% = 0
	    20 - 39% = 94
	    40 - 59% = 163
	    60 - 79% = 84
	    80 - 99% = 30

    Index PSTORNED_SND_ID (1)
	Root page: 783, depth: 2, leaf buckets: 300, nodes: 552691
	Average node length: 5.60, total dup: 495215, max dup: 71
	Average key length: 2.77, compression ratio: 3.25
	Average prefix length: 8.34, average data length: 0.66
	Clustering factor: 105320, ratio: 0.19
	Fill distribution:
	     0 - 19% = 0
	    20 - 39% = 13
	    40 - 59% = 126
	    60 - 79% = 106
	    80 - 99% = 55
 
DOC_DATA recs=952'232, vers=21'087, swept pages=1'913
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
DOC_DATA (145)
    Primary pointer page: 214, Index root page: 215
    Total formats: 1, used formats: 1
    Average record length: 47.31, total records: 952232
    Average version length: 29.57, total versions: 21087, max versions: 3
    Average fragment length: 0.00, total fragments: 0, max fragments: 0
    Average unpacked length: 72.00, compression ratio: 1.52
    Pointer pages: 2, data page slots: 5221
    Data pages: 5221, average fill: 73%
    Primary pages: 5221, full pages: 4205, swept pages: 1913
    Fill distribution:
	 0 - 19% = 0
	20 - 39% = 0
	40 - 59% = 8
	60 - 79% = 5211
	80 - 99% = 2

    Index DOC_DATA_DOC_WARE_UNQ (1)
	Root page: 41547, depth: 3, leaf buckets: 2388, nodes: 952232
	Average node length: 18.76, total dup: 0, max dup: 0
	Average key length: 15.86, compression ratio: 1.70
	Average prefix length: 14.14, average data length: 12.86
	Clustering factor: 115600, ratio: 0.12
	Fill distribution:
	     0 - 19% = 0
	    20 - 39% = 361
	    40 - 59% = 1897
	    60 - 79% = 26
	    80 - 99% = 104

    Index DOC_DATA_ID_DESC (2)
	Root page: 100522, depth: 3, leaf buckets: 1573, nodes: 952232
	Average node length: 11.71, total dup: 0, max dup: 0
	Average key length: 8.82, compression ratio: 1.02
	Average prefix length: 3.18, average data length: 5.82
	Clustering factor: 56449, ratio: 0.06
	Fill distribution:
	     0 - 19% = 0
	    20 - 39% = 276
	    40 - 59% = 1297
	    60 - 79% = 0
	    80 - 99% = 0

    Index FK_DOC_DATA_DOC_LISTS (3)
	Root page: 944, depth: 2, leaf buckets: 905, nodes: 952232
	Average node length: 6.47, total dup: 741864, max dup: 48
	Average key length: 3.58, compression ratio: 2.51
	Average prefix length: 7.64, average data length: 1.36
	Clustering factor: 85372, ratio: 0.09
	Fill distribution:
	     0 - 19% = 63
	    20 - 39% = 195
	    40 - 59% = 597
	    60 - 79% = 17
	    80 - 99% = 33

    Index FK_DOC_DATA_DOC_LISTS_OP_DID (4)
	Root page: 840, depth: 2, leaf buckets: 853, nodes: 968801
	Average node length: 6.98, total dup: 752780, max dup: 122
	Average key length: 4.08, compression ratio: 6.61
	Average prefix length: 25.14, average data length: 1.86
	Clustering factor: 85475, ratio: 0.09
	Fill distribution:
	     0 - 19% = 0
	    20 - 39% = 64
	    40 - 59% = 729
	    60 - 79% = 44
	    80 - 99% = 16

    Index FK_DOC_DATA_WARES (5)
	Root page: 975, depth: 2, leaf buckets: 399, nodes: 952232
	Average node length: 4.90, total dup: 951832, max dup: 2628
	Average key length: 2.01, compression ratio: 4.48
	Average prefix length: 8.99, average data length: 0.01
	Clustering factor: 763858, ratio: 0.80
	Fill distribution:
	     0 - 19% = 0
	    20 - 39% = 0
	    40 - 59% = 3
	    60 - 79% = 295
	    80 - 99% = 101

    Index PK_DOC_DATA (0)
	Root page: 668, depth: 2, leaf buckets: 793, nodes: 952232
	Average node length: 11.71, total dup: 0, max dup: 0
	Average key length: 8.81, compression ratio: 1.02
	Average prefix length: 3.18, average data length: 5.82
	Clustering factor: 56449, ratio: 0.06
	Fill distribution:
	     0 - 19% = 1
	    20 - 39% = 0
	    40 - 59% = 2
	    60 - 79% = 121
	    80 - 99% = 669
Это состояние таблиц - оно какое, нормальное или уже давно "ку-ку" ?
PS. Свипа за минувшие 15 часов не было ни разу.
...
Рейтинг: 0 / 0
10.07.2014, 13:22:47
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38693101
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvhvladЗвучит как отмазка :) пусть Таблоид свой тест на голом RC проверитНе попрёт он на этом TIL. Сразу же некосистентные данные будут, отрицательные остатки на складе etc.
...
Рейтинг: 0 / 0
10.07.2014, 13:23:57
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38693173
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидhvladНе нужен он тебеПочему ? как ты это понял ?OIT не застряла, мусор катастрофически не накапливается - чё те ещё надо ? :)

ТаблоидВот, например, текущие данные по 5 самым меняемым таблицам:А с чем мне сравнивать эти текущие данные ? Динамика где ?

ТаблоидЭто состояние таблиц - оно какое, нормальное или уже давно "ку-ку" ?PDISTR мне не нравится, в остальных не вижу поводов для беспокойства.
...
Рейтинг: 0 / 0
10.07.2014, 13:56:50
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38693230
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladс чем мне сравнивать эти текущие данные ? Динамика где ?Вот динамика:
 
снимки версий через каждые 2 часа (первый - также через 2 часа после начала теста)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
176.
177.
178.
179.
180.
181.
182.
183.
184.
185.
186.
187.
188.
189.
190.
191.
192.
193.
194.
195.
196.
197.
198.
199.
200.
201.
202.
203.
204.
205.
206.
207.
208.
209.
210.
211.
212.
213.
214.
215.
216.
217.
218.
219.
220.
221.
222.
223.
224.
225.
226.
227.
228.
229.
230.
231.
232.
233.
234.
235.
236.
237.
238.
239.
240.
241.
242.
243.
244.
245.
246.
247.
248.
249.
250.
251.
252.
253.
254.
255.
256.
257.
258.
259.
260.
261.
262.
263.
264.
265.
266.
267.
268.
269.
270.
271.
272.
273.
274.
275.
276.
277.
278.
279.
280.
281.
282.
283.
284.
285.
286.
287.
288.
289.
290.
291.
292.
09 23:21:02 2014: DOC_DATA (145)
09 23:21:02 2014:     Primary pointer page: 214, Index root page: 215
09 23:21:02 2014:     Total formats: 1, used formats: 1
09 23:21:02 2014:     Average record length: 47.24, total records: 285725
09 23:21:02 2014:     Average version length: 31.29, total versions: 1197, max versions: 2
09 23:21:02 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
09 23:21:02 2014: --
09 23:21:02 2014: PDISTR (153)
09 23:21:02 2014:     Primary pointer page: 243, Index root page: 244
09 23:21:02 2014:     Total formats: 1, used formats: 1
09 23:21:02 2014:     Average record length: 17.72, total records: 3735
09 23:21:02 2014:     Average version length: 29.01, total versions: 3947, max versions: 6
09 23:21:02 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
09 23:21:02 2014: --
09 23:21:02 2014: PSTORNED (154)
09 23:21:02 2014:     Primary pointer page: 245, Index root page: 246
09 23:21:02 2014:     Total formats: 1, used formats: 1
09 23:21:02 2014:     Average record length: 52.04, total records: 199295
09 23:21:02 2014:     Average version length: 30.33, total versions: 2474, max versions: 2
09 23:21:02 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
09 23:21:02 2014: --
09 23:21:02 2014: QDISTR (151)
09 23:21:02 2014:     Primary pointer page: 239, Index root page: 240
09 23:21:02 2014:     Total formats: 1, used formats: 1
09 23:21:02 2014:     Average record length: 67.86, total records: 1685051
09 23:21:02 2014:     Average version length: 42.33, total versions: 25741, max versions: 4
09 23:21:02 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
09 23:21:02 2014: --
09 23:21:02 2014: QSTORNED (152)
09 23:21:02 2014:     Primary pointer page: 241, Index root page: 242
09 23:21:02 2014:     Total formats: 1, used formats: 1
09 23:21:02 2014:     Average record length: 72.51, total records: 1553746
09 23:21:02 2014:     Average version length: 40.66, total versions: 10850, max versions: 2
09 23:21:02 2014:     Average fragment length: 21.67, total fragments: 61, max fragments: 1

-------------------------

10 01:21:03 2014: DOC_DATA (145)
10 01:21:03 2014:     Primary pointer page: 214, Index root page: 215
10 01:21:03 2014:     Total formats: 1, used formats: 1
10 01:21:03 2014:     Average record length: 47.60, total records: 460505
10 01:21:03 2014:     Average version length: 31.35, total versions: 637, max versions: 3
10 01:21:03 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
10 01:21:03 2014: --
10 01:21:03 2014: PDISTR (153)
10 01:21:03 2014:     Primary pointer page: 243, Index root page: 244
10 01:21:03 2014:     Total formats: 1, used formats: 1
10 01:21:03 2014:     Average record length: 17.10, total records: 5154
10 01:21:03 2014:     Average version length: 26.74, total versions: 6593, max versions: 6
10 01:21:03 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
10 01:21:03 2014: --
10 01:21:03 2014: PSTORNED (154)
10 01:21:03 2014:     Primary pointer page: 245, Index root page: 246
10 01:21:03 2014:     Total formats: 1, used formats: 1
10 01:21:03 2014:     Average record length: 52.70, total records: 279977
10 01:21:03 2014:     Average version length: 30.76, total versions: 2924, max versions: 2
10 01:21:03 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
10 01:21:03 2014: --
10 01:21:03 2014: QDISTR (151)
10 01:21:03 2014:     Primary pointer page: 239, Index root page: 240
10 01:21:03 2014:     Total formats: 1, used formats: 1
10 01:21:03 2014:     Average record length: 68.61, total records: 2978170
10 01:21:03 2014:     Average version length: 42.91, total versions: 14281, max versions: 4
10 01:21:03 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
10 01:21:03 2014: --
10 01:21:03 2014: QSTORNED (152)
10 01:21:03 2014:     Primary pointer page: 241, Index root page: 242
10 01:21:03 2014:     Total formats: 1, used formats: 1
10 01:21:03 2014:     Average record length: 73.00, total records: 2150529
10 01:21:03 2014:     Average version length: 39.76, total versions: 6270, max versions: 2
10 01:21:03 2014:     Average fragment length: 17.79, total fragments: 56, max fragments: 1

-------------------------

10 03:21:01 2014: DOC_DATA (145)
10 03:21:01 2014:     Primary pointer page: 214, Index root page: 215
10 03:21:01 2014:     Total formats: 1, used formats: 1
10 03:21:01 2014:     Average record length: 47.53, total records: 599409
10 03:21:01 2014:     Average version length: 25.06, total versions: 6676, max versions: 3
10 03:21:01 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
10 03:21:01 2014: --
10 03:21:01 2014: PDISTR (153)
10 03:21:01 2014:     Primary pointer page: 243, Index root page: 244
10 03:21:01 2014:     Total formats: 1, used formats: 1
10 03:21:01 2014:     Average record length: 7.39, total records: 25637
10 03:21:01 2014:     Average version length: 29.57, total versions: 37947, max versions: 6
10 03:21:01 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
10 03:21:01 2014: --
10 03:21:01 2014: PSTORNED (154)
10 03:21:01 2014:     Primary pointer page: 245, Index root page: 246
10 03:21:01 2014:     Total formats: 1, used formats: 1
10 03:21:01 2014:     Average record length: 52.52, total records: 342986
10 03:21:01 2014:     Average version length: 31.51, total versions: 9322, max versions: 2
10 03:21:01 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
10 03:21:01 2014: --
10 03:21:01 2014: QDISTR (151)
10 03:21:01 2014:     Primary pointer page: 239, Index root page: 240
10 03:21:01 2014:     Total formats: 1, used formats: 1
10 03:21:01 2014:     Average record length: 67.36, total records: 4149145
10 03:21:01 2014:     Average version length: 43.07, total versions: 181589, max versions: 5
10 03:21:01 2014:     Average fragment length: 55.20, total fragments: 5, max fragments: 1
10 03:21:01 2014: --
10 03:21:01 2014: QSTORNED (152)
10 03:21:01 2014:     Primary pointer page: 241, Index root page: 242
10 03:21:01 2014:     Total formats: 1, used formats: 1
10 03:21:01 2014:     Average record length: 72.57, total records: 2535058
10 03:21:01 2014:     Average version length: 41.02, total versions: 48244, max versions: 2
10 03:21:01 2014:     Average fragment length: 17.79, total fragments: 56, max fragments: 1

-------------------------

10 05:21:10 2014: DOC_DATA (145)
10 05:21:10 2014:     Primary pointer page: 214, Index root page: 215
10 05:21:10 2014:     Total formats: 1, used formats: 1
10 05:21:10 2014:     Average record length: 47.57, total records: 699918
10 05:21:10 2014:     Average version length: 25.55, total versions: 7922, max versions: 3
10 05:21:10 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
10 05:21:10 2014: --
10 05:21:10 2014: PDISTR (153)
10 05:21:10 2014:     Primary pointer page: 243, Index root page: 244
10 05:21:10 2014:     Total formats: 1, used formats: 1
10 05:21:10 2014:     Average record length: 7.96, total records: 29411
10 05:21:10 2014:     Average version length: 29.53, total versions: 42909, max versions: 10
10 05:21:10 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
10 05:21:10 2014: --
10 05:21:10 2014: PSTORNED (154)
10 05:21:10 2014:     Primary pointer page: 245, Index root page: 246
10 05:21:10 2014:     Total formats: 1, used formats: 1
10 05:21:10 2014:     Average record length: 52.50, total records: 408935
10 05:21:10 2014:     Average version length: 31.29, total versions: 14224, max versions: 2
10 05:21:10 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
10 05:21:10 2014: --
10 05:21:10 2014: QDISTR (151)
10 05:21:10 2014:     Primary pointer page: 239, Index root page: 240
10 05:21:10 2014:     Total formats: 1, used formats: 1
10 05:21:10 2014:     Average record length: 67.83, total records: 4955644
10 05:21:10 2014:     Average version length: 42.01, total versions: 150390, max versions: 5
10 05:21:10 2014:     Average fragment length: 55.40, total fragments: 10, max fragments: 1
10 05:21:10 2014: --
10 05:21:10 2014: QSTORNED (152)
10 05:21:10 2014:     Primary pointer page: 241, Index root page: 242
10 05:21:10 2014:     Total formats: 1, used formats: 1
10 05:21:10 2014:     Average record length: 72.54, total records: 2798474
10 05:21:10 2014:     Average version length: 40.64, total versions: 58222, max versions: 2
10 05:21:10 2014:     Average fragment length: 20.24, total fragments: 59, max fragments: 1

--------------------------

10 07:21:02 2014: DOC_DATA (145)
10 07:21:02 2014:     Primary pointer page: 214, Index root page: 215
10 07:21:02 2014:     Total formats: 1, used formats: 1
10 07:21:02 2014:     Average record length: 47.39, total records: 785627
10 07:21:02 2014:     Average version length: 27.05, total versions: 15559, max versions: 3
10 07:21:02 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
10 07:21:02 2014: --
10 07:21:02 2014: PDISTR (153)
10 07:21:02 2014:     Primary pointer page: 243, Index root page: 244
10 07:21:02 2014:     Total formats: 1, used formats: 1
10 07:21:02 2014:     Average record length: 9.03, total records: 57858
10 07:21:02 2014:     Average version length: 29.33, total versions: 83208, max versions: 10
10 07:21:02 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
10 07:21:02 2014: --
10 07:21:02 2014: PSTORNED (154)
10 07:21:02 2014:     Primary pointer page: 245, Index root page: 246
10 07:21:02 2014:     Total formats: 1, used formats: 1
10 07:21:02 2014:     Average record length: 51.85, total records: 465446
10 07:21:02 2014:     Average version length: 31.51, total versions: 29234, max versions: 2
10 07:21:02 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
10 07:21:02 2014: --
10 07:21:02 2014: QDISTR (151)
10 07:21:02 2014:     Primary pointer page: 239, Index root page: 240
10 07:21:02 2014:     Total formats: 1, used formats: 1
10 07:21:02 2014:     Average record length: 67.35, total records: 5729917
10 07:21:02 2014:     Average version length: 42.86, total versions: 249666, max versions: 5
10 07:21:02 2014:     Average fragment length: 55.40, total fragments: 5, max fragments: 1
10 07:21:02 2014: --
10 07:21:02 2014: QSTORNED (152)
10 07:21:02 2014:     Primary pointer page: 241, Index root page: 242
10 07:21:02 2014:     Total formats: 1, used formats: 1
10 07:21:02 2014:     Average record length: 71.79, total records: 2988630
10 07:21:02 2014:     Average version length: 41.03, total versions: 123270, max versions: 2
10 07:21:02 2014:     Average fragment length: 22.45, total fragments: 62, max fragments: 1

-------------------------

10 09:21:13 2014: DOC_DATA (145)
10 09:21:13 2014:     Primary pointer page: 214, Index root page: 215
10 09:21:13 2014:     Total formats: 1, used formats: 1
10 09:21:13 2014:     Average record length: 47.56, total records: 845314
10 09:21:13 2014:     Average version length: 25.53, total versions: 11747, max versions: 3
10 09:21:13 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
10 09:21:13 2014: --
10 09:21:13 2014: PDISTR (153)
10 09:21:13 2014:     Primary pointer page: 243, Index root page: 244
10 09:21:13 2014:     Total formats: 1, used formats: 1
10 09:21:13 2014:     Average record length: 15.39, total records: 45976
10 09:21:13 2014:     Average version length: 29.31, total versions: 52988, max versions: 10
10 09:21:13 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
10 09:21:13 2014: --
10 09:21:13 2014: PSTORNED (154)
10 09:21:13 2014:     Primary pointer page: 245, Index root page: 246
10 09:21:13 2014:     Total formats: 1, used formats: 1
10 09:21:13 2014:     Average record length: 51.88, total records: 498298
10 09:21:13 2014:     Average version length: 31.40, total versions: 31848, max versions: 2
10 09:21:13 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
10 09:21:13 2014: --
10 09:21:13 2014: QDISTR (151)
10 09:21:13 2014:     Primary pointer page: 239, Index root page: 240
10 09:21:13 2014:     Total formats: 1, used formats: 1
10 09:21:13 2014:     Average record length: 68.19, total records: 6265279
10 09:21:13 2014:     Average version length: 43.18, total versions: 128694, max versions: 4
10 09:21:13 2014:     Average fragment length: 55.40, total fragments: 5, max fragments: 1
10 09:21:13 2014: --
10 09:21:13 2014: QSTORNED (152)
10 09:21:13 2014:     Primary pointer page: 241, Index root page: 242
10 09:21:13 2014:     Total formats: 1, used formats: 1
10 09:21:13 2014:     Average record length: 71.99, total records: 3047857
10 09:21:13 2014:     Average version length: 40.69, total versions: 108116, max versions: 2
10 09:21:13 2014:     Average fragment length: 27.93, total fragments: 71, max fragments: 1

-------------------------

10 11:21:06 2014: DOC_DATA (145)
10 11:21:06 2014:     Primary pointer page: 214, Index root page: 215
10 11:21:06 2014:     Total formats: 1, used formats: 1
10 11:21:06 2014:     Average record length: 47.11, total records: 909999
10 11:21:06 2014:     Average version length: 27.88, total versions: 29298, max versions: 3
10 11:21:06 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
10 11:21:06 2014: --
10 11:21:06 2014: PDISTR (153)
10 11:21:06 2014:     Primary pointer page: 243, Index root page: 244
10 11:21:06 2014:     Total formats: 1, used formats: 1
10 11:21:06 2014:     Average record length: 12.77, total records: 104333
10 11:21:06 2014:     Average version length: 29.51, total versions: 130780, max versions: 8
10 11:21:06 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
10 11:21:06 2014: --
10 11:21:06 2014: PSTORNED (154)
10 11:21:06 2014:     Primary pointer page: 245, Index root page: 246
10 11:21:06 2014:     Total formats: 1, used formats: 1
10 11:21:06 2014:     Average record length: 50.02, total records: 541972
10 11:21:06 2014:     Average version length: 31.48, total versions: 73250, max versions: 2
10 11:21:06 2014:     Average fragment length: 45.50, total fragments: 4, max fragments: 1
10 11:21:06 2014: --
10 11:21:06 2014: QDISTR (151)
10 11:21:06 2014:     Primary pointer page: 239, Index root page: 240
10 11:21:06 2014:     Total formats: 1, used formats: 1
10 11:21:06 2014:     Average record length: 66.83, total records: 6963637
10 11:21:06 2014:     Average version length: 43.80, total versions: 389777, max versions: 5
10 11:21:06 2014:     Average fragment length: 55.25, total fragments: 4, max fragments: 1
10 11:21:06 2014: --
10 11:21:06 2014: QSTORNED (152)
10 11:21:06 2014:     Primary pointer page: 241, Index root page: 242
10 11:21:06 2014:     Total formats: 1, used formats: 1
10 11:21:06 2014:     Average record length: 70.19, total records: 3178836
10 11:21:06 2014:     Average version length: 40.93, total versions: 268434, max versions: 2
10 11:21:06 2014:     Average fragment length: 28.94, total fragments: 97, max fragments: 1

--------------------------
10 13:21:03 2014: DOC_DATA (145)
10 13:21:03 2014:     Primary pointer page: 214, Index root page: 215
10 13:21:03 2014:     Total formats: 1, used formats: 1
10 13:21:03 2014:     Average record length: 47.21, total records: 957614
10 13:21:03 2014:     Average version length: 29.42, total versions: 25117, max versions: 3
10 13:21:03 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
10 13:21:03 2014: --
10 13:21:03 2014: PDISTR (153)
10 13:21:03 2014:     Primary pointer page: 243, Index root page: 244
10 13:21:03 2014:     Total formats: 1, used formats: 1
10 13:21:03 2014:     Average record length: 17.09, total records: 87805
10 13:21:03 2014:     Average version length: 29.55, total versions: 93390, max versions: 14
10 13:21:03 2014:     Average fragment length: 0.00, total fragments: 0, max fragments: 0
10 13:21:03 2014: --
10 13:21:03 2014: PSTORNED (154)
10 13:21:03 2014:     Primary pointer page: 245, Index root page: 246
10 13:21:03 2014:     Total formats: 1, used formats: 1
10 13:21:03 2014:     Average record length: 50.48, total records: 557499
10 13:21:03 2014:     Average version length: 31.52, total versions: 66152, max versions: 2
10 13:21:03 2014:     Average fragment length: 45.67, total fragments: 6, max fragments: 1
10 13:21:03 2014: --
10 13:21:03 2014: QDISTR (151)
10 13:21:03 2014:     Primary pointer page: 239, Index root page: 240
10 13:21:03 2014:     Total formats: 1, used formats: 1
10 13:21:03 2014:     Average record length: 67.70, total records: 7398308
10 13:21:03 2014:     Average version length: 44.25, total versions: 249951, max versions: 4
10 13:21:03 2014:     Average fragment length: 56.00, total fragments: 1, max fragments: 1
10 13:21:03 2014: --
10 13:21:03 2014: QSTORNED (152)
10 13:21:03 2014:     Primary pointer page: 241, Index root page: 242
10 13:21:03 2014:     Total formats: 1, used formats: 1
10 13:21:03 2014:     Average record length: 70.51, total records: 3183856
10 13:21:03 2014:     Average version length: 40.91, total versions: 239792, max versions: 2
10 13:21:03 2014:     Average fragment length: 34.61, total fragments: 88, max fragments: 1
...
Рейтинг: 0 / 0
10.07.2014, 14:23:42
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38693774
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидВот динамика:Суть не изменилась:hvladPDISTR мне не нравится, в остальных не вижу поводов для беспокойства.
...
Рейтинг: 0 / 0
10.07.2014, 19:34:48
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38693796
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvlad P DISTR мне не нравится, в остальных не вижу поводов для беспокойства.А почему ты остался равнодушным к Q distr ? ведь в ней более 25% записей имеют версии и больше всего swept pages (это те страницы, что должны быть убраны мусорщиком - так ?
...
Рейтинг: 0 / 0
10.07.2014, 20:00:59
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38693799
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидбольше всего swept pages (это те страницы, что должны быть убраны мусорщиком - так ?
с точностью до наоборот
...
Рейтинг: 0 / 0
10.07.2014, 20:07:36
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38693802
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Если так, то получается, что мусорщик трудится над этой таблицей в поте лица, но версий в ней всё равно полно... Настораживает как-то...
Какое процент версий относительно общего числа записей считается уже "тревожным" ? (например, в тулзах типа IBAnalyst - там есть вроде бы подсветка, но какие там эвристики применяются для этого ?
...
Рейтинг: 0 / 0
10.07.2014, 20:12:44
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38693815
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидА почему ты остался равнодушным к Q distr ? ведь в ней более 25% записей имеют версиКол-во знаков посчитай. Где ты 25% нашёл ?

total records: 7398308
total versions: 249951

не дотягивает и до 4%
...
Рейтинг: 0 / 0
10.07.2014, 20:36:41
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38693817
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladКол-во знаков посчитай. Где ты 25% нашёл ?пардон, глаза замылились ужо... :-[
...
Рейтинг: 0 / 0
10.07.2014, 20:45:06
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38694725
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
ТаблоидВот, например, текущие данные по 5 самым меняемым таблицаммнда... в 2.5 SuperClassic всё гораздо хреновее.
Вот что вижу через полтора часа после начала молотьбы, всё те же 200 окон:
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
DOC_DATA (308)
    Primary pointer page: 194, Index root page: 195
    Average record length: 45.80, total records: 230637
    Average version length: 16.60, total versions: 28493, max versions: 12
    Data pages: 1228, data page slots: 1228, average fill: 77%
    Fill distribution:
--
PDISTR (317)
    Primary pointer page: 229, Index root page: 230
    Average record length: 12.80, total records: 105016
    Average version length: 29.22, total versions: 130700, max versions: 6
    Data pages: 1099, data page slots: 1100, average fill: 53%
    Fill distribution:
--
PSTORNED (318)
    Primary pointer page: 231, Index root page: 232
    Average record length: 23.33, total records: 108536
    Average version length: 30.85, total versions: 126674, max versions: 2
    Data pages: 718, data page slots: 718, average fill: 89%
    Fill distribution:
--
QDISTR (315)
    Primary pointer page: 225, Index root page: 226
    Average record length: 64.29, total records: 2385737
    Average version length: 42.07, total versions: 259256, max versions: 3
    Data pages: 16194, data page slots: 16194, average fill: 79%
    Fill distribution:
--
QSTORNED (316)
    Primary pointer page: 227, Index root page: 228
    Average record length: 53.67, total records: 259303
    Average version length: 38.88, total versions: 130393, max versions: 2
    Data pages: 1781, data page slots: 1781, average fill: 88%
    Fill distribution:
OST застрял вообще, кажись, намертво:

Код: plaintext
1.
2.
3.
4.
Oldest transaction      414763
Oldest active           414764
Oldest snapshot         285121
Next transaction        628280

PS. Изменённые параметры firebird.conf:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
DefaultDbCachePages = 8192
ExternalFileAccess = Restrict /var/db/fb25
FileSystemCacheThreshold = 1000000
LockHashSlots = 22111
LockMemSize = 16777216
MaxUserTraceLogSize = 9999
RemoteServicePort = 3252
TempBlockSize = 104857600
TempCacheLimit = 1073741824
TempDirectories = /dev/shm;/tmp
...
Рейтинг: 0 / 0
11.07.2014, 18:53:42
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38694741
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Таблоид,

у тебя не "ost застрял", а у тебя настоящих роллбэков нет. Что есть большая разница. Автосвип не срабатывает, и не должен. Все отлично.
...
Рейтинг: 0 / 0
11.07.2014, 19:49:47
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38694742
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Таблоид,

вернее, "все отлично", за исключением того, что
600к Next - за какой интервал времени?
OAT торчит 1/3 этого интервала. Причем, OAT эта есть snapshot. Отсюда OST уехал на 2/3 интервала Next.

если 600к это полтора часа, значит OAT существует уже полчаса. Если это "молотилки", то как это у них транзакции по полчаса живут?
...
Рейтинг: 0 / 0
11.07.2014, 19:52:58
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38694746
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvзначит OAT существует уже полчаса. Если это "молотилки", то как это у них транзакции по полчаса живут?Кхе! А вот живут! :-)
Вот счетчики на сейчас:
Код: plaintext
1.
2.
3.
4.
Oldest transaction      633738
Oldest active            633739 
Oldest snapshot         414764
Next transaction        944177


Лезу в мониторинг за номером аттача и тем, что он там делает:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
SQL> commit; select * from mon$transactions where mon$transaction_id= 633739 ;

MON$TRANSACTION_ID              633739
MON$ATTACHMENT_ID                68 
MON$STATE                       1
MON$TIMESTAMP                   2014-07-11 18:52:54.0820
MON$TOP_TRANSACTION             633739
MON$OLDEST_TRANSACTION          414763
MON$OLDEST_ACTIVE               285121
MON$ISOLATION_MODE              1
MON$LOCK_TIMEOUT                0
MON$READ_ONLY                   0
MON$AUTO_COMMIT                 0
MON$AUTO_UNDO                   0
MON$STAT_ID                     1852

Лезу теперь с стейтменты - и вижу, что он пытается осилить "подъем инвойса" (это обычно очень затратное дело, т.к. надо резервы клиентов создавать, сторнировать количества по ним и проч.):
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
SQL> commit; select * from mon$statements where mon$attachment_id=68;

MON$STATEMENT_ID                1726832
MON$ATTACHMENT_ID               68
MON$TRANSACTION_ID              <null>
MON$STATE                       0
MON$TIMESTAMP                   <null>
MON$SQL_TEXT                    0:16
select rdb$db_key from doc_list where  id = ? and ( ? is null or exists( select id from v_add_invoice_to_stock  v where v.id = ? ))
MON$STAT_ID                     29

MON$STATEMENT_ID                1726831
MON$ATTACHMENT_ID               68
MON$TRANSACTION_ID              <null>
MON$STATE                       0
MON$TIMESTAMP                   <null>
MON$SQL_TEXT                    0:18
select id from v_add_invoice_to_stock  where id >= ? order by id rows 1
MON$STAT_ID                     30

MON$STATEMENT_ID                1726830
MON$ATTACHMENT_ID               68
MON$TRANSACTION_ID              <null>
MON$STATE                       0
MON$TIMESTAMP                   <null>
MON$SQL_TEXT                    0:1a
select max(id)+0.5 from v_add_invoice_to_stock
MON$STAT_ID                     31

MON$STATEMENT_ID                1726829
MON$ATTACHMENT_ID               68
MON$TRANSACTION_ID              <null>
MON$STATE                       0
MON$TIMESTAMP                   <null>
MON$SQL_TEXT                    0:1c
select min(id)-0.5 from v_add_invoice_to_stock
MON$STAT_ID                     32

MON$STATEMENT_ID                1726828
MON$ATTACHMENT_ID               68
MON$TRANSACTION_ID              633739
MON$STATE                       1
MON$TIMESTAMP                   2014-07-11 18:53:04.2640
MON$SQL_TEXT                    0:1e
execute block returns( invoice_id bigint, total_lines int, total_invoice_qty int, res_ok int, res_err int )
as
   declare v_this dm_dbobj;
begin
    v_this = 'isql:sp_add_invoice_to_stock';
    --execute procedure sp_add_to_perf_log(v_this||':exists?');
    if ( exists( select * from v_add_invoice_to_stock ) ) then
    begin
      --execute procedure sp_add_to_perf_log(v_this||':exists?');

      execute procedure sp_add_to_perf_log(v_this||':run_sp');
      select
        min(p.doc_list_id)
        ,count(*)
        ,sum(p.qty)
        ,min(p.res_ok)
        ,min(p.res_err)
      from  sp_add_invoice_to_stock  p   -- iter # 13
           --~~~~~~~~~~~~~~~~~~~~~~~~
      into invoice_id, total_lines, total_invoice_qty, res_ok, res_err;
      suspend;

      execute procedure sp_add_to_perf_log(v_this||':run_sp', null,'doc_id='||invoice_id);
   end
   else
   begin
      --execute procedure sp_add_to_perf_log(v_this||':exists?', null,'no rows in view');
   end
end
MON$STAT_ID                     33

MON$STATEMENT_ID                8394
MON$ATTACHMENT_ID               68
MON$TRANSACTION_ID              <null>
MON$STATE                       0
MON$TIMESTAMP                   <null>
MON$SQL_TEXT                    <null>
MON$STAT_ID                     34

MON$STATEMENT_ID                8393
MON$ATTACHMENT_ID               68
MON$TRANSACTION_ID              <null>
MON$STATE                       0
MON$TIMESTAMP                   <null>
MON$SQL_TEXT                    <null>
MON$STAT_ID                     35

MON$STATEMENT_ID                8392
MON$ATTACHMENT_ID               68
MON$TRANSACTION_ID              <null>
MON$STATE                       0
MON$TIMESTAMP                   <null>
MON$SQL_TEXT                    <null>
MON$STAT_ID                     36

А теперь включаю трейс для аттача № 68, предварительно выставив в его конфиге почти всё в ON:
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
  enabled true
#  log_sweep true
  log_errors true

  ####################   A C H T U N G  ##############
  time_threshold 0
  connection_id 68
  ####################################################

  log_connections true
  log_transactions true

  log_statement_prepare true
  log_statement_start true
  log_statement_free true
  log_trigger_start true
  log_procedure_start true

  log_statement_finish true
  log_procedure_finish true
  log_trigger_finish true

#  print_plan true
  print_perf true
  max_sql_length 16384
  max_log_size 9999999999
- и с "внезапным изумлением" вижу, что в трейсе вроде как всё шевелится, но... как в замедленной съемке:
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
2014-07-11T20:01:50.6250 (6216:0x7f16ff0a3018) EXECUTE_PROCEDURE_START
	oltp25 (ATT_68, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
	C:\MIX\firebird\fb25\bin\isql.exe:2488
		(TRA_633739, CONCURRENCY | NOWAIT | READ_WRITE)

Procedure FN_OPER_RETAIL_RESERVE:

2014-07-11T 20:01:50.6250  (6216:0x7f16ff0a3018) EXECUTE_PROCEDURE_FINISH
	oltp25 (ATT_68, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
	C:\MIX\firebird\fb25\bin\isql.exe:2488
		(TRA_633739, CONCURRENCY | NOWAIT | READ_WRITE)

Procedure FN_OPER_RETAIL_RESERVE:
      0 ms

2014-07-11T 20:01:51.1580  (6216:0x7f16ff0a3018) EXECUTE_PROCEDURE_START
	oltp25 (ATT_68, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
	C:\MIX\firebird\fb25\bin\isql.exe:2488
		(TRA_633739, CONCURRENCY | NOWAIT | READ_WRITE)

Procedure FN_OPER_RETAIL_RESERVE:

2014-07-11T20:01:51.1580 (6216:0x7f16ff0a3018) EXECUTE_PROCEDURE_FINISH
	oltp25 (ATT_68, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
	C:\MIX\firebird\fb25\bin\isql.exe:2488
		(TRA_633739, CONCURRENCY | NOWAIT | READ_WRITE

Т.е. опять старая загадка: "ЧТО там делается около 500 мс между возвратом из одной ХП и вызовом другой ?".
Похоже, я тут переоцениваю сильно возможности своего сервака: у него просто не хватает дыхалки (ядер ?) на 200 молотилок. Поэтому аттачи должны просто тупо ЖДАТЬ, пока сервак ими займётся.
...
Рейтинг: 0 / 0
11.07.2014, 20:14:15
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38694760
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Таблоид> Т.е. опять старая загадка: "ЧТО там делается около 500 мс
Таблоид> между возвратом из одной ХП и вызовом другой ?".

Интересно, от кого ты ждёшь ответ по имеющейся инфе?
Или тебе без разницы какой он - правильный или нет -
лишь бы что-то поменять/покрутить?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
11.07.2014, 20:39:02
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38694765
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Гаджимурадов РустамТаблоид> Т.е. опять старая загадка: "ЧТО там делается около 500 мс
Таблоид> между возвратом из одной ХП и вызовом другой ?".

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

Вот, полюбуйся:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
2014-07-11T20:36:05.1790 (6216:0x7f16ff0a3018) EXECUTE_PROCEDURE_START
        oltp25 (ATT_68, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:2488
                (TRA_633739, CONCURRENCY | NOWAIT | READ_WRITE)

Procedure FN_OPER_RETAIL_RESERVE:

2014-07-11T20:36: 05 .1790 (6216:0x7f16ff0a3018) EXECUTE_PROCEDURE_FINISH
        oltp25 (ATT_68, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:2488
                (TRA_633739, CONCURRENCY | NOWAIT | READ_WRITE)

Procedure FN_OPER_RETAIL_RESERVE:
      0 ms

2014-07-11T20:36: 53 .1910 (6216:0x7f16ff0a3018) EXECUTE_PROCEDURE_START
        oltp25 (ATT_68, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:2488
                (TRA_633739, CONCURRENCY | NOWAIT | READ_WRITE)

Procedure SP_ADD_TO_PERF_LOG:
param0 = varchar(80), "sp_make_qty_storno"
param1 = integer, "<NULL>"
param2 = varchar(255), "locked=10, skipped=0, scanned=13"
param3 = double precision, "<NULL>"
param4 = double precision, "<NULL>"

Непонятная пауза между финишем одного модуля и началом другого длилась 48 сек.
Причём, слово "модуль" для FN_OPER_RETAIL_RESERVE - это слишком громко сказано: она возвращает значение контекстной переменной или же считавает её из таблицы настроек. Но контекстная переменная задаётся на старте сессии, так что в таблицу точно лазить нужды не было.
...
Рейтинг: 0 / 0
11.07.2014, 20:55:59
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38694772
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
> Непонятная пауза между финишем одного модуля и началом другого длилась 48 сек.

А между ними ничего не было, никаких действий?
Про остальные 199 коннектов пока промолчим.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
11.07.2014, 21:24:42
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38694776
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Гаджимурадов Рустам> Непонятная пауза между финишем одного модуля и началом другого длилась 48 сек.

А между ними ничего не было, никаких действий?
Про остальные 199 коннектов пока промолчим.
нет, не было! ведь я в трейсе всё включил, чтобы показывалось...
и в трёшке, кстати, такое уже видел: какие-то необъяснимые паузы между окончанием одной deterministic-функции (из своего кеша выдёргивает число и выдаёт его!) и началом другой. Но тогда я отловил дельты в 1-2 сек, такого апофеоза не было.
...
Рейтинг: 0 / 0
11.07.2014, 21:27:11
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38694779
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
OMG, тройка, да ещё deterministic... Ну-ну.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
11.07.2014, 21:30:23
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38694785
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
дык я проверял их, детерминистики эти: всё там гут, работают гораздо быстрее, чем rdb$get_context'ы :-)
...
Рейтинг: 0 / 0
11.07.2014, 21:51:17
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38697269
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladТаблоидну, я вот смотрю в garbage_collection.pdf (материалы "транзакционного семинара"), и там из написанного на стр. 27 делаю вывод: автозапуск свипа движком происходит, когда “sweep gap” : OST - OIT достигает лимита, либо дефолтного (20000), либо проставленного врукопашную.Ну так какие ещё вопросы ?А вопросы таки появились.
Ибо не знаю, что там поменяли в последнем снапшоте, но теперь автосвип стартует при отрицательной разнице OST - OIT.
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
oel64   Tue Jul 15 22:57:38 2014
        /opt/fb30trnk/bin/fbguard: /opt/fb30trnk/bin/firebird terminated abnormally (-1)



oel64   Tue Jul 15 22:57:38 2014
        /opt/fb30trnk/bin/fbguard: guardian starting /opt/fb30trnk/bin/firebird



oel64   Tue Jul 15 22:57:45 2014
        Sweep is started by SWEEPER
        Database "oltp30"
         OIT 192249 , OAT 192250,  OST 152759 , Next 221145


oel64   Tue Jul 15 22:58:05 2014
        Sweep is finished
        Database "oltp30"
        OIT 221145, OAT 221595, OST 221195, Next 224359


oel64   Tue Jul 15 23:00:42 2014
        /opt/fb30trnk/bin/fbguard: /opt/fb30trnk/bin/firebird terminated abnormally (-1)



oel64   Tue Jul 15 23:00:42 2014
        /opt/fb30trnk/bin/fbguard: guardian starting /opt/fb30trnk/bin/firebird



oel64   Tue Jul 15 23:00:46 2014
        Sweep is started by SWEEPER
        Database "oltp30"
         OIT 227402,  OAT 227403,  OST 222170 , Next 237566


oel64   Tue Jul 15 23:01:03 2014
        Sweep is finished
        Database "oltp30"
        OIT 237566, OAT 237873, OST 237603, Next 240283
То, что там заваливается ФБ - это пока не интересно :-) /к тому же, я скинул ДЕ эти две бактрассы/.
А вот то, что при sweep interval = 1000 (одна тысяча) и отрицательной разнице OST - OIT свип уже два раза стартанул - занятно...

PS. LI-T3.0.0.31226
...
Рейтинг: 0 / 0
15.07.2014, 23:18:53
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38697278
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Интересно, понимаешь ли ты, что такое OST и когда
в действительности должен стартовать автосвип... :)

Впрочем, я в исходники не глядел (тем более снапшота),
может алгоритм, действительно, поменяли.

P.S. Проверь ещё на 2.5 - там точно не могли поменять.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
15.07.2014, 23:33:34
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38697416
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Гаджимурадов РустамИнтересно, понимаешь ли ты, что такое OST и когда
в действительности должен стартовать автосвип... :)Что такое OST, я стал (кажется :)) понимать только после семинара. Там еще АК хорошую метафору привёл про самого аксакала (почившего в бозе), о котором еще помнит самый старый из живущих ныне аксакалов :-)
Автосвип должен стартовать, когда OST - OIT достигает лимита (дефолт = 20000).

Теперь выложи сюда своё видение этого (я про OST и когда автосвип стартует), чтобы сравнить... :-)

Гаджимурадов РустамP.S. Проверь ещё на 2.5 - там точно не могли поменять.Этого не было вплоть до недавних билдов 3.0 (последний, который я интенсивно юзал перед этим - 31208). Не знаю почему, но свип этот два раза автостартанул примерно в те моменты, когда я запускал трейс. Дальше я трейс перестал запускать и оставил на ночь - и автосвип тоже не запускался уже ни разу. Но может, так совпало.
...
Рейтинг: 0 / 0
16.07.2014, 07:53:47
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38697683
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоидhvladпропущено...
Ну так какие ещё вопросы ?А вопросы таки появились.
Ибо не знаю, что там поменяли в последнем снапшоте, но теперь автосвип стартует при отрицательной разнице OST - OIT.Свип стартует так, как уже 100500 раз описано, ничего в этом плане не менялось.
sweep gap вычисляется исходя из обновлённых значений счётчиков, которые ещё не попали на header page (ибо незачем делать 2 подряд записи header page на диск).
А вот в лог пишутся значения из header page, которая получит обновлённые значения счётчиков несколько позже (например, при старте след.тр-ции).
Посмотри на новое значение OIT и вспомни, что свип его устанавливает равным тому значению OST, которое было в момент старта свипа.
...
Рейтинг: 0 / 0
16.07.2014, 11:34:39
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38697782
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladsweep gap вычисляется исходя из обновлённых значений счётчиков, которые ещё не попали на header page (ибо незачем делать 2 подряд записи header page на диск).
А вот в лог пишутся значения из header page, которая получит обновлённые значения счётчиков несколько позже (например, при старте след.тр-ции).А нельзя ли в лог записывать именно те значения счетчиков, которые и послужили стартом автосвипу, а не то, что сейчас ?
...
Рейтинг: 0 / 0
16.07.2014, 12:42:33
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38697826
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидА нельзя ли в лог записывать именно те значения счетчиков, которые и послужили стартом автосвипу, а не то, что сейчас ?Короткий ответ - нет.

Можно, в принципе, сравнивать значения из header page с текущими кешированными в памяти значениями и писать в лог более свежие, но для [супер]классика это не будет работать.
...
Рейтинг: 0 / 0
16.07.2014, 13:15:06
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38697954
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
hvladМожно, в принципе, сравнивать значения из header page с текущими кешированными
в памяти значениями и писать в лог более свежие, но для [супер]классика это не будет
работать.
Т.е. у вас там в птичьем потрохе есть код, который сравнивает два значения, а в лог при
этом пишет совершенно левую хрень?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
16.07.2014, 14:18:06
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38698017
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Dimitry SibiryakovТ.е. у вас там в птичьем потрохе***

PS 2модератор - мне пофигу, что ты со этим всем сделаешь, но терперь идиотов я не буду.
...
Рейтинг: 0 / 0
16.07.2014, 15:17:56
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38698094
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
hvladидиотов я не буду.
Т.е. взять код, принимающий решение о запуске автосвипа, который сравнивает два числа и
добавить именно в него вывод в лог именно этих двух чисел это какая-то идиотская логика,
да? Обязательно надо выводить в лог совершенно другие числа, которые могут быть сильно
отличными от первых и на основе которых вообще нельзя понять с какого перепою было принято
решение о запуске?.. Ню-ню...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
16.07.2014, 16:18:08
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38698221
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Dimitry SibiryakovТ.е. взять код, принимающий решение о запуске автосвипа, который сравнивает два числа и
добавить именно в него вывод в лог именно этих двух чисел это какая-то идиотская логика,
да?

Подумай, сколько тысяч раз раз во время работы свипа возникает это состояние и что будет, если писать всё это в лог именно в этот момент.
...
Рейтинг: 0 / 0
16.07.2014, 17:45:10
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38698275
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
hvladПодумай, если осталось чем, сколько тысяч раз раз во время работы свипа
возникает это состояние и что будет, если писать всё это в лог именно в этот момент.
Лог переполнится сообщениями и кому-нибудь таки придётся сделать так, чтобы
пользовательские транзакции не делали дурную работу пытаясь запустить уже запущенный свип.
Возможно, это даже решит проблему "у нас во время работы свипа всё тормозит".
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
16.07.2014, 18:31:24
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38698317
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Dimitry SibiryakovЛог переполнится сообщениямиГыыы.... спасибо, паржал!
Беспокойство по переполнению лога при том, что сейчас туда прёт спам вида 'errno=104 /110' (сотни строк в день!) - оно излишнее, КМК...
...
Рейтинг: 0 / 0
16.07.2014, 19:32:32
| Ответить | Цитировать | Написать  
auto sweep: должен ли он стартовать, если OST < OIT ?
    #38698602
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WildSery
Участник
ТаблоидБеспокойство по переполнению лога при том, что сейчас туда прёт спам вида 'errno=104 /110' (сотни строк в день!) - оно излишнее, КМК...Это сарказм?
Если нет, то перечитай ещё раз посты выше. От сотен тоже не благодать, а вот тысячи записей это никуда не годится.
...
Рейтинг: 0 / 0
17.07.2014, 09:45:19
| Ответить | Цитировать | Написать  
72 сообщений из 72, показаны все 3 страниц
  все  
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / auto sweep: должен ли он стартовать, если OST < OIT ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=40&tid=1563466]:
 0ms
get settings:
 6ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 187ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 59ms
get tp. blocked users:
 1ms
others: 213ms
total:  496ms
созд. / загр.: 496ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]