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

[zVlad]

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

Объясняю
Да, 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]

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

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

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

[Dmitry67]

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

[zVlad]

Объясняю
Да, 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]

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]

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

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

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

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

[tengiz]

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

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

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

[Dmitry67]

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

[tengiz]

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

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

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