Задача перехвата DML-запросов и как она решается разными DB

oMoses · Post by **oMoses** » 29 Jun 2004 16:54

verzlo wrote:Вы пропустили logical standby - по моему он должен удовлетворить условиям задачи...

Это будет сродни стрельбы из пушки по воробьям. Да и ограничений там масса... Да и все от того-же LogMinera пляшет.

zVlad · Post by **zVlad** » 29 Jun 2004 17:25

Dmitry67 wrote:zVlad, Вы все время говорите о том как классно что сама ОС ведает памятью и для sp, и для сервера. Однако это очень неоптимальное решение c точки зрения performance. Потмоу что возникает авто(само)конкуренция за ресурс

.....

Scenario, you are describing, is a very common and unavoidable problem when you have limits. And solutions could be:

1. If you want to guaranty that, at any time, responce times for either table scan, or SP runs must be the same regardless SP ran or not, then you have to either increase memory on your computer, or reduce cash for tables.

2. If you can afford to have different responce time you mignt not need to do anything and relay on OS paging mechanism. This scenario is more common, just because you would never know all requirments. By the way, it could happen for other than SP memory requests. What should happen here? Looks like MS SQL will now not be aware about it?

In MF world, we initially calculate all memory requirments, and perform step called capacity planning. Then we monitor how system works, do we have any paging? If "Yes" we either add more memory or reduce space used for different pools (cashes).
Also, I susspect that scenario, you gave at the end of your last message, is not applicable to describe how DB2 and zOS would work together. I don't have enough to say for sure, but most likelly they will work like DB2 is "aware" about its pages are stolen, and zOS will not write data pages to the page data sets if those pages were not cnahged. I'll try to find more about it, it seems interesting to know.

Dmitry67 · Post by **Dmitry67** » 29 Jun 2004 20:34

zVlad, я только что рассказал как это решает MS
Поэтому слово unavoidable я с Вашего позволения отнесу к DB2

zVlad · Post by **zVlad** » 29 Jun 2004 20:43

Dmitry67 wrote:zVlad, я только что рассказал как это решает MS
Поэтому слово unavoidable я с Вашего позволения отнесу к DB2

Don't be hurry. First, explain what happen if pages will be stolen from memory by some other than MS SQL processes running on the same system?

I've found that in case of DB2 and zOS there is no co-operations. If zOS decides to stole page allocated for DB2 it will do it without having to let DB2 know about it.

Of course, DB2 will control all memory requests caming from within its own address space. But, SP for DB2 on zOS never executed in DB2 memory.

Dmitry67 · Post by **Dmitry67** » 29 Jun 2004 20:52

Объясняю
Да, SQL server страдает от page faults если другой процесс будет отбирать память
Если другой процесс или другие процессы расходуют примерно постоянное количество памяти то можно все рассчитать и ограничить SQL server по памяти
Если он сконфигурирован с выделением памяти по умлочанию то он сам попытается это сделать. Однако только задним числом, и, если процесс периодический (набухает и сдувается) то ничего хорошего из этого не выйдет
Именно поэтому Microsoft рекомендует для SQL server выделенный сервер для production, и не ставить более одной инстанции на сервер

Однако с sp другая вещь. Вы можете разнести аппликации на другие сервера... но не sp... без узерба производительности. Поэтому в отношении памяти sp сервер ДОЛЖЕН быть aware и не должен полагаться на os

zVlad · Post by **zVlad** » 29 Jun 2004 21:17

Seee my comments in english (I don't have cyrrilic at work) below.

Dmitry67 wrote:Объясняю
Да, SQL server страдает от page faults если другой процесс будет отбирать память
Если другой процесс или другие процессы расходуют примерно постоянное количество памяти то можно все рассчитать и ограничить SQL server по памяти - this is what we try to do on MF constantly.

Если он сконфигурирован с выделением памяти по умлочанию то он сам попытается это сделать. Однако только задним числом, и, если процесс периодический (набухает и сдувается) то ничего хорошего из этого не выйдет
Именно поэтому Microsoft рекомендует для SQL server выделенный сервер для production, и не ставить более одной инстанции на сервер - which is not recommended for MF. Instead, it is recommended to have more different workloads in order to utilize computer resources efficiently. With recommendations, Microsoft made, you will be always underloaded, your resources will be used inefficiently. Do you agree?

Однако с sp другая вещь. Вы можете разнести аппликации на другие сервера... но не sp... без узерба производительности. And you've got network overhead. Congradulation. Поэтому в отношении памяти sp сервер ДОЛЖЕН быть aware и не должен полагаться на os - or SP should run as a separate from database server process like it was done for DB2, but still on the same image of operating system, and system must be responsible for resources handling, and controlling. What's wrong here?

Dmitry67 · Post by **Dmitry67** » 29 Jun 2004 21:23

zVlad, да, это могло бы контролироваться системой если бы система поддерживала навороченный API который бы позволял системе сообщать процесаам зарегистрированным как cache memory keepers, что требуется 'поджаться'. Система могла бы сообщать процессам что надо release(size) bytes, или наоборот, можно аллокировать столько то памяти

Интересно что в этом случае и обычный дисковый cache мог бы быть реализован без хитростей как обычный процесс. Но такого нет

Поэтому еслинственный выход - сделать такую интерграцию хотя бы не врамках система в рамках базы.

Dmitry67 · Post by **Dmitry67** » 29 Jun 2004 21:25

По поводу выделенного сервера
Я частично соглашусь
С точки зрения ЦЕНЫ да
С точки зрения максимизации производительности SQL server - нет
Зависит от того какая цель

zVlad · Post by **zVlad** » 29 Jun 2004 21:27

Dmitry67 wrote:Объясняю
Да, SQL server страдает от page faults если другой процесс будет отбирать память
.....
Однако с sp другая вещь. Вы можете разнести аппликации на другие сервера... но не sp... без узерба производительности. Поэтому в отношении памяти sp сервер ДОЛЖЕН быть aware и не должен полагаться на os

Actually, it is OK for those arcitectures, and principles of works are used for Intel, Windows, and MS SQL. What you tell me is pretty logical and understandable.

But other approaches could be more efficient with other sets of architectures, principles of works, and so on. Those approaches are also logically correct and robust.

Answer here is that again we try to compare apples and oranges. As usual. Agree?

zVlad · Post by **zVlad** » 29 Jun 2004 21:39

Dmitry67 wrote:zVlad, да, это могло бы контролироваться системой если бы система поддерживала навороченный API который бы позволял системе сообщать процесаам зарегистрированным как cache memory keepers, что требуется 'поджаться'. Система могла бы сообщать процессам что надо release(size) bytes, или наоборот, можно аллокировать столько то памяти

.....

Exactly. Or those cashes, with their sources (say, files, with page structures, where tables reside) should be defined on operating system level (like page files!!!), so OS be "aware", when data are backed up, to avoid unneeded IOs.
I discussed this issue with our MVS system programmers, he said it is contradiction to MVS principles of works. He said MVS shouldn't care about such details of processes.
But in VM, which like more than any others, there are such options call: "stored segments", and "stored systems". It is not exactly what database server could use but it would be a good base for that. I wouldn't surprise if DB2 for VM is already using it.

Dmitry67 · Post by **Dmitry67** » 29 Jun 2004 22:05

Спасибо что поговорили с системщиками
Я понимаю их ответ но...

Думаю проблема идет на самом деле очень издалека
Существующая система виртуальной памяти работает в общем со страницами paged memory двух типов: read-write, которые при вытеснении пишутся в pagefile, и readonly (которые часто executable), которые при вытеснении не надо писать в pagefile потмоу что они могут быть считаны непосредственно из EXE

На самом деле сущеествуют и страницы третьего типа, страницы кешей. Записывать их в pagefile бессмысленно потому что тони являются буквальными или реконструируемыми копиями данных на диске которые и так уже есть.

Аппаратным решением было бы гененирить особый page fault при вытесненным страницам такого типа, который бы обрабатывался не системой а аппликацией... Но чего нет того нет.

tengiz · Post by **tengiz** » 29 Jun 2004 22:26

Dmitry67 wrote:На самом деле сущеествуют и страницы третьего типа, страницы кешей. Записывать их в pagefile бессмысленно потому что тони являются буквальными или реконструируемыми копиями данных на диске которые и так уже есть.

Аппаратным решением было бы гененирить особый page fault при вытесненным страницам такого типа, который бы обрабатывался не системой а аппликацией... Но чего нет того нет.

Для этого существует универсальный механизм, который можно найти практически в любой современной операционной системе - mеmory mapped files. Другое дело, что для нужд баз данных с их WAL это не совсем подходит, но дисковый кеш общего назначения (особенно на системах с 64-битной адресацией,) реализованный на mmf - это очень удобно.

Dmitry67 · Post by **Dmitry67** » 29 Jun 2004 22:33

tengiz, Я хотел задать вопрос про SQL 64 bit и mmf, а потом подумал про read ahead и промолчал

tengiz · Post by **tengiz** » 30 Jun 2004 01:42

Dmitry67 wrote:tengiz, Я хотел задать вопрос про SQL 64 bit и mmf, а потом подумал про read ahead и промолчал

Да чего уж - это не называется промолчал. Это называется сам задал и тут же сам ответил

.

Да, read-ahead это, разумеется, не одобрит, но это не смертельно. А вот WAL совсем не будет работать. Что для сервера БД уже фатально.