размер кэша базы

aaa3d · Сообщение **aaa3d** » 05 дек 2005, 12:02

вопрос по размеру кэша страниц базы и размеру собственно страницы
FB 1.5.2. super
база около гигабайта.

предистория...
где то в нете видел что не стоит ставить буфер более 10000 страниц.
так-же видел, что используя NTFS желательно использовать размер страницы 4К (во избежание лишнего чтения)
так и сделал.... (получается кэш 40МБ)

сейчас занимаюсь оптимизацией отчетов. отчет по остаткам товаров
у меня строится минут 5 и при настройке кэширования как указал выше
чтений с диска более 100тыс. (данные довольно сильно раскиданы по
базе и к сожалению читать их последовательно не представляется возможным, т.е. страницы из кэша постоянно вытесняются новыми.)

при увеличении страницы до 16К и размера буфера до 20К (общий кэш 320МБ) получаю построение отчета около минуты, операций чтения с диска - 7000 (вывод - все нужные страницы читаются в кэш один раз).

(кстати, если размер кэша делать меньше, то по идее вместо самой базы
страницы будет кэшировать операционка. так вроде и происходит, но скорость выполнения запроса - процентов на 30 меньше вроде)

однако помимо построения отчетов база раз в 15 минут синхронизируется с 5 другими (обновление-вставка порядка 10000 записей) и на ней также работает 15 человек.
так вот, при большом размере кэша базы сервак у нас начинает весьма ощутимо сваповаться и получается совсем плохо (памяти на серваке - 1гиг)

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

прошу извинить за длинный пост

Сообщение **kdv** » 05 дек 2005, 17:03

где то в нете видел что не стоит ставить буфер более 10000 страниц.

это было давно. В любом случае подбирается экспериментально, и для Классика больше 1024 страниц кэша ставить вредно.

ак-же видел, что используя NTFS желательно использовать размер страницы 4К

не то. размер страницы БД 4-8К, и соответственно размер кластера NTFS.

получаю построение отчета около минуты

ну и замечательно. есть еще такой общий совет - вместо того чтобы подобными отчетами каждый раз мусолить одни и те же исходные данные, желательно накапливать агрегатные значения (подсуммы), которые и считать. В зависимости от объема данных и места субагрегатов ускорение чтения может быть до десятков тысяч раз.

как правильнее поступать с размером страницы

универсального ответа нет, увы.

Ivan_Pisarevsky

Если памяти физически не хватает, то припарки помогут врядли... Как вариант попробовать поставить линух повыбросить нафиг графику, пару сотен мегабайт достанется файрберду... но относительно такого варианта добить еще гиг памяти проще на порядок.

А насчет середины: вот и попробуйте 8 килобайт страницу и нтфс-ный кластер соотв. 8 килобайт.

План этого длинного запроса как выглядит?

aaa3d · Сообщение **aaa3d** » 06 дек 2005, 11:55

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

ПЛАН. показать думаю нереально, т.к. это не один запрос
а куча последовательных: отображение остатков товара, пришедших ранее
определенной даты.
соответственно процедуры:
список товаров -> список прихода товара(дата, количество, код) ->
->остатки на указанном приходе(количество).

соответственно, данный отчет порсматривает базу за весь период
использования. видимо, придется вводить какие то промежуточные таблицы
чтобы по все базу много раз не искать записи.

NATURAL в планах нет.

Сообщение **kdv** » 06 дек 2005, 12:57

NATURAL в планах нет.

в смысле? Плакать надо, а не радоваться.

Ivan_Pisarevsky

У меня за год в таблицу по складским операциям наколотили примерно 40 тысяч записей, собрать из этого добра оборотку за любой период примерно 3-5 секунд, причем за это время набирается псевдовременная таблица, потом из нее группировки и фетч на клиента. вся база примерно мег 150. В другом месте по аналогичной таблице, правда там записей поменьше тыщ 25, оборотка собирается вообще меньше чем за секунду, но тут алгоритм я подоптимизировал, выкинул нафиг временную таблицу, все запихал в селективную ХП.

если грубо линейно экстраполировать на 1000 мег, у вас должно собираться за полминуты где-то, при этом сервер у меня 1400 п4 + 256 мег памяти.

aaa3d · Сообщение **aaa3d** » 06 дек 2005, 15:07

Ну, если пошли дебаты..... продолжим

примерные параметры базы:
товаров около 65к (стройматериалы)
записей передвижения товара - в среднем 2000 в день
(приходы, расходы, перемещения, списания, т.д.)
табличка учета товара по количеству - 520000 запичей.
расчет остатков я имею в виду не по количеству а по себестоимости -
соответственно себестоимость берется из таблиц приходов и определяется,
сколько с каждого прихода было списано по табличке расходов).

по поводу плакать по поводу отсутствиая NATURAL...

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

при страницах в кэше среднее время фетча - 10мс (думаю, что неплохое время, и NATURAL туда прилеплять не надо)

для себя делаю вывод, что при такой логике построения отчетов выход один -
добавить памяти, о операционка ее будет в своем кэше держать (замедление - процентов 10 от того, что база будет кэшировать страницы сама)

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

aaa3d · Сообщение **aaa3d** » 06 дек 2005, 16:25

условия выполнения тестирования

компьютер:
AthlonXP 2500. 1024 RAM, HDD Seagate 200 GB 7200 (8MB)
WinXP prof SP2, FB 1.5.3, IbExpert
База: ~1000 MB, 96 таблиц. учет товарооборота оптово/розничной торговой фирмы

выполняется одна и та же сложная хранимая процедура,
которая выводит список коваров с себестоимостью и датой закупки,
которые лежат на складе всыше 6 месяцев (т.к. она строится по всему периоду,
то ядру базы приходится читать множество страниц данных)

построения: (1,3,3... - построение с пустыми буферами, 1_ (2_, 3_) повторное выполнение
№ page_size(kb) page_buffer time(sec)
1 4096 50 322
1_ 4096 50 6
2 4096 40000 283
2_ 4096 40000 3,5
3 16384 50 73
3_ 16384 50 10,5
4 16394 10000 63
4_ 16384 10000 4,6
5 16384 20000 54
5_ 16384 20000 3,4

Enchanced Info:
+--------------------------+-----------+-----------+-------------+---------+---------+---------+
| Table Name | Records | Indexed | Non-Indexed | Updates | Deletes | Inserts |
| | Total | reads | reads | | | |
+--------------------------+-----------+-----------+-------------+---------+---------+---------+
| PN$| 0 | 5961 | 0 | 0 | 0 | 0 |
| PNS$| 0 | 6019 | 0 | 0 | 0 | 0 |
| PSORT| 0 | 165 | 0 | 0 | 0 | 0 |
| PSORTS| 0 | 165 | 0 | 0 | 0 | 0 |
| RE| 0 | 30825 | 0 | 0 | 0 | 0 |
| REG| 0 | 53996 | 0 | 0 | 0 | 0 |
| RN| 0 | 1196 | 0 | 0 | 0 | 0 |
| RNS| 0 | 27665 | 0 | 0 | 0 | 0 |
| SPISS| 0 | 53 | 0 | 0 | 0 | 0 |
| TW| 0 | 3463 | 0 | 0 | 0 | 0 |
| TWTREE| 0 | 1048 | 2545 | 0 | 0 | 0 |
+--------------------------+-----------+-----------+-------------+---------+---------+---------+

Сообщение **kdv** » 06 дек 2005, 16:59

которые лежат на складе всыше 6 месяцев (т.к. она строится по всему периоду,
то ядру базы приходится читать множество страниц данных)

я ж говорю, промежуточные суммы надо хранить. чего зря по всем этим записям каждый раз елозить. А если их за 12 или 18 месяцев накопится, будет еще в 2 3- раза тормознее?

aaa3d · Сообщение **aaa3d** » 06 дек 2005, 23:39

Согласен. так и сделаю.

а для себя сделал вывод (может и еще кому нибудь пригодится)

если в базе происходят интенсивные чтения, и при этом она не вся
находится в любом кэше (базы или операционки), то размер страницы надо делать не равным размеру кластера файловой системы, а просто делать его максимальным (16к). по крайней мере в моем случае
увеличние скорости наблюдается в 5 раз.

хотя такой подход не решает мою проблему полностью и я согласен с kdv,
что лучше заняться построением промежуточных итогов - эффект будет выше.

всем спасибо

Ivan_Pisarevsky

Хранимые агрегаты... записей-то вроде всего полмиллиона, должно и без них спокойно вертеться.

Я, например, все то что приходуется на склад тут же считаю отгруженым, т.е. есть специально обученая расходка которая будет израсходована в махнадцать каком то году, таким образом показ остатков сводится к показу одной накладной, выборка естественно идет по индексу и отрабатывается очень быстро. Если надо остаток на определенное число, независимо от наличия, отбираю все то что принято ДО, а израсходовано ПОСЛЕ. вобщем фильтровка идет по индексированому полю дата_документа, джойны на спецификации и справочники по индескированым ключам. то бишь то что израсходовано ДО спокойно отсеивается индексом и сервер их с диска не читает.

выполняется одна и та же сложная хранимая процедура,
которая выводит список коваров с себестоимостью и датой закупки,
которые лежат на складе всыше 6 месяцев (т.к. она строится по всему периоду,
то ядру базы приходится читать множество страниц данных)

Не вижу я здесь необходимости читать ВСЮ базу... хотя я ж не знаю вашей структуры...

Ivan_Pisarevsky

И еще я б вместо второго камня собрал бы дисковую ПС хотя бы из пары сказевых шпинделей(а лучше 4) и рэйд адаптер с собственной считалкой и кэшем. Это будет не дороже двухголовой матери и пары камней.

Ritter · Сообщение **Ritter** » 09 дек 2005, 15:03

kvd

это было давно. В любом случае подбирается экспериментально, и для Классика больше 1024 страниц кэша ставить вредно.

А можно немного по подробнее?
Почему вредно более 1024? У меня на classic кэш 8192 на базу. Может стоит уменьшить?

Сообщение **kdv** » 09 дек 2005, 15:44

У меня на classic кэш 8192 на базу. Может стоит уменьшить?

экспериментируй. может быть и побыстрее будет. Проблема большого кэша в классике возникает отсюда:

у каждого процесса классика кэш свой. Поэтому если страница в кэше одного из процессов модифицируется, то для того, чтобы эту страницу увидели другие процессы, этот процесс должен ее ЗАПИСАТЬ на диск, а другие - ПРОЧИТАТЬ. Соответственно, чем чаще модификация страниц, тем чаще их ПЕРЕЧИТЫВАНИЕ, если, конечно, другие процессы заинтересованы в этих страницах. В результате может возникнуть ухудшение производительности почти в геометрической прогрессии, соответствующее увеличению кэша.

Кроме того, 8к страниц кэша при размере страницы 8килобайт - это 16мегабайт на процесс. 10 процессов - минимум 200 мегабайт RAM. И так далее.