Коннект к базе и запросы select вызывают запись в базу

bazilio77
Дата: 12.07.2012 17:45:12
Здравствуйте!

Изучал тут намедни тормоза записи в базу, обнаружил, что коннект и запросы select приводят к записи в файл БД.
Для меня понятно, что нужно где-то зафиксировать транзакцию и ее параметры, выполнить уборку мусора и т.д.
немного был удивлен количеством записей.
kdv
Дата: 12.07.2012 23:45:39
bazilio77,
мля, старт транзакции должен записать состояние в Header Page. Если есть мусор, то чтение данных его должно убрать. И т.д.
Задолбало, вообще-то, излагать прописные истины на форуме, когда все это есть на ibase.ru.
bazilio77
Дата: 13.07.2012 21:32:09
kdv
bazilio77,
мля, старт транзакции должен записать состояние в Header Page. Если есть мусор, то чтение данных его должно убрать. И т.д.
Задолбало, вообще-то, излагать прописные истины на форуме, когда все это есть на ibase.ru.


Уважаемый Дмитрий. Прописные истины я знаю.
Ключевая фраза в моем вопросе была -
УДИВЛЕН КОЛИЧИСТВУ ЗАПИСЕЙ.

См. тред по сравнению производительности 2.5 и 3.0 dimitr сказал что интербейз хе где то быстрее, в связи с отложенной записью заголовка.

Как раз совпало с моими терзаниями по записи.

С тем вопросом я так до конца не понял как можно иметь нормальные дисковые бенчмарки и иметь проблемы с firebird.
dimitr
Дата: 13.07.2012 22:53:00
bazilio77
Ключевая фраза в моем вопросе была -
УДИВЛЕН КОЛИЧИСТВУ ЗАПИСЕЙ.

а ты где-то привел это количество и ситуацию, при котором оно возникает? Может ты двум дисковым записям удивляешься, отсюда не видно.
bazilio77
Дата: 14.07.2012 15:48:18
3981
dimitr
bazilio77
Ключевая фраза в моем вопросе была -
УДИВЛЕН КОЛИЧИСТВУ ЗАПИСЕЙ.

а ты где-то привел это количество и ситуацию, при котором оно возникает? Может ты двум дисковым записям удивляешься, отсюда не видно.


поковырялся немного получилась следующая раскладка:
Для чистоты эксперимента подключался isql к базе оставшейся после FBTest.
Думаю что результат интересный.

коннект 4 записи. Я так понял 2 записи собственно коннект 2 записи старт транзакции?

Time of Day,"Process Name","PID","Operation","Path","Result","Detail"
15:27:46,7812880,"fbserver.exe","2916","WriteFile","D:\temp\test.FdB","SUCCESS","Offset: 0, Length: 8 192, I/O Flags: Write Through, Priority: Normal"
15:27:46,7822789,"fbserver.exe","2916","WriteFile","D:\temp\test.FdB","SUCCESS","Offset: 0, Length: 8 192, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal"
15:27:46,7833916,"fbserver.exe","2916","WriteFile","D:\temp\test.FdB","SUCCESS","Offset: 0, Length: 8 192, I/O Flags: Write Through, Priority: Normal"
15:27:46,7835358,"fbserver.exe","2916","WriteFile","D:\temp\test.FdB","SUCCESS","Offset: 0, Length: 8 192, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal"

select count(*) from test; конечно вызвал уборку мусора и показал очень большое количество записей. Тут вопросов нет.
повторный селект после коммита дал 0 ноль записей.

коммит 8 записей. коммит абсолютно холостой, т.е сказал коммит стер записи в мониторе, затем еще раз коммит.


Time of Day,"Process Name","PID","Operation","Path","Result","Detail"
15:35:27,4244247,"fbserver.exe","2916","WriteFile","D:\temp\test.FdB","SUCCESS","Offset: 0, Length: 8 192, I/O Flags: Write Through, Priority: Normal"
15:35:27,4245806,"fbserver.exe","2916","WriteFile","D:\temp\test.FdB","SUCCESS","Offset: 0, Length: 8 192, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal"
15:35:27,4256408,"fbserver.exe","2916","WriteFile","D:\temp\test.FdB","SUCCESS","Offset: 0, Length: 8 192, I/O Flags: Write Through, Priority: Normal"
15:35:27,4257802,"fbserver.exe","2916","WriteFile","D:\temp\test.FdB","SUCCESS","Offset: 0, Length: 8 192, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal"
15:35:27,4270977,"fbserver.exe","2916","WriteFile","D:\temp\test.FdB","SUCCESS","Offset: 1 196 032, Length: 8 192, I/O Flags: Write Through, Priority: Normal"
15:35:27,4272415,"fbserver.exe","2916","WriteFile","D:\temp\test.FdB","SUCCESS","Offset: 1 196 032, Length: 8 192, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal"
15:35:27,4285375,"fbserver.exe","2916","WriteFile","D:\temp\test.FdB","SUCCESS","Offset: 1 196 032, Length: 8 192, I/O Flags: Write Through, Priority: Normal"
15:35:27,4286654,"fbserver.exe","2916","WriteFile","D:\temp\test.FdB","SUCCESS","Offset: 1 196 032, Length: 8 192, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal"
kdv
Дата: 16.07.2012 11:01:56
bazilio77
Ключевая фраза в моем вопросе была -
УДИВЛЕН КОЛИЧИСТВУ ЗАПИСЕЙ.

а я не удивлен. если изменений в таблице не было - сколько ее ни читай, никаких "записей" не будет. И не там ты вообще смотришь.
Нужно смотреть
- в performance analysis в IBExpert при выполнении запроса, читающий запрос покажет writes, если была сборка мусора
- в диспетчер задач, столбцы "прочитано байт", "записано байт".
Впрочем, можно и в process monitor смотреть, но это если тебя интересует, какие именно страницы были изменены.

bazilio77
коммит 8 записей. коммит абсолютно холостой, т.е сказал коммит стер записи в мониторе, затем еще раз коммит.

чем ты запросы исполняешь к БД? Учитывай, что IBExpert на каждый запрос в SQL Editor стартует и завершает штук 5 транзакций, как минимум.

И, в приводимых даных всего 2 изменения страниц:
1 обновление header page, второе - страницы с номером 1196032/8192 = 146