Компьютерный форум OSzone.net  

Компьютерный форум OSzone.net (http://forum.oszone.net/index.php)
-   Общий по Linux (http://forum.oszone.net/forumdisplay.php?f=9)
-   -   Как ограничить объем памяти, используемый Linux под buff/cache память? (http://forum.oszone.net/showthread.php?t=338234)

GrayMagellan 14-12-2018 16:10 2845964

Как ограничить объем памяти, используемый Linux под buff/cache память?
 
Всем привет! Очень мне не нравится, что в Линукс так свободно (как гно в проруби) болтается память, выделяемая под кэширование файловых операций ввода-вывода. У меня все жестко в системе - в ящике столько-то ОЗУ, из него столько-то памяти выделено под базу данных (Оракл), и все было бы хорошо, если бы не прыгающий туда-сюда buff/cache!!! То он 100 Мб, то 900 Мб, то опять 600. Из-за этого я не могу выделить памяти базе больше. Ибо если я пытаюсь это сделать, косвенно требуя от Линукс передать память от файловых буферов базе данных, то кажется мне, что это не срабатывает, и buff/cache начинает дико свопить, сливая накопленные в файловом кэше данные на диск, и упорно считая, что под buff/cache должно выделяться от 0 до 1 Гб ОЗУ. А если это не получается разместить в ОЗУ, то оно прет в своп. Я бы хотел в ОС память жестко под buff/cache выделить (скажем, 50 Мб), а освободившуюся память отдать базе. У Оракла свои механизмы работы с кэшем базы данных, и buff/cache не кэширует потоки из кэша базы к/от файлам базы. Как это сделать?!

Фразы типа "Linux always tries to use RAM to speed up disk operations by using available memory for buffers (file system metadata) and cache (pages with actual contents of files or block devices). This helps the system to run faster because disk information is already in memory which saves I/O operations. If space is needed by programs or applications like Oracle, then Linux will free up the buffers and cache to yield memory for the applications." я уже читал. Не всем и не всегда такая политика подходит. В ситуации, когда ты вручную конфигурируешь память туда, сюда и вооон туда, неподдающийся управлению компонент в виде самовольно растущей или сжимающейся buff/cache памяти очень сильно раздражает и сковывает.

GrayMagellan 14-12-2018 17:36 2845980

Вот реальный пример:

[oracle@.!.]$ free -m
total | used | free | shared | buff/cache | available
Mem: 7710 | 7436 | 51 | 26 | 222 | 92
Swap: 8063 | 60 | 8003
[oracle@.!.]$

Спрашивается, какого рожна система выделила под файловый кэш 222 Мб ОЗУ, и при этом в своп улетела на 60!!! Гораздо логичнее было бы не выделять так много ОЗУ под файловый кэш, и тогда бы не пришлось залезать в своп.

shisik 14-12-2018 22:11 2846030

GrayMagellan, а почему бы просто не вырубить swap? И проблемы не будет. Линукс под кеш не выделит памяти больше, чем есть свободно. А будет там гипотетически полезный дисковый кеш или просто абра-кадабра от ошмётков данных - кого это волнует?

Busla 15-12-2018 11:26 2846092

Цитата:

Цитата GrayMagellan
У Оракла свои механизмы работы с кэшем базы данных, и buff/cache не кэширует потоки из кэша базы к/от файлам базы. »

Цитата:

Цитата GrayMagellan
какого рожна система выделила под файловый кэш 222 Мб ОЗУ »

AFAIK он не файловый, а страничный.
Кэш - это буфер, который не сразу освобождается. Чтобы что-то (oracle в том числе) могло работать с данными на диске, они должны лежать в кэше.

GrayMagellan 16-12-2018 09:49 2846310

Цитата:

Цитата shisik
а почему бы просто не вырубить swap? И проблемы не будет »

С Windows я в таком режиме уже 15 лет работаю, и вырубаю файл подкачки на всех подконтрольных мне машинах - домашних/личных, рабочих станциях, и даже на некоторых серверах на работе (там, где я хорошо знаю работающий софт и уверен, что он не вылетит за границы имеющегося ОЗУ). Но в мире Linux я новичок, а в "чужой монастырь со своим уставом не ходят". Раз положено своп - я его сделал. К тому же наличие свопа на машине - одно из предваритварительных требований установки Oracle Database. Хотя я полагаю, что база, в принципе, хоть и требует наличия свопа, при достаточном объеме ОЗУ будет нормально работать. Но, в целом, я пока из-за недостаточности опыта администрирования Linux и Oracle Database боюсь отказываться от свопа в этой ОС.

Но знаете... В принципе я думаю что своп тут не причем - у меня вопрос об ограничении выделяемого ОС объема памяти под buff/cache, проходящего по строке Mem. А это ведь исключительно ОЗУ? Ну отключу я своп. А это приведет к тому, что Linux по строке Mem прекратит выделять такие гигантские объемы памяти? И станет ли он выделять память в том объеме, как я хочу, а не как он решит?

Цитата:

Цитата Busla
AFAIK он не файловый, а страничный »

Да, насколько я понял из документации на Oracle Database, у базы данных свои механизмы работы с памятью и диском. В моем случае я имею на сервере 8 Гб ОЗУ, из которых 6 хочу отдать под базу данных. Эти отданные базе 6 Гб я хочу поделить на 3/4 под SGA и 1/4 под PGA. База будет 12cR2, там полного автомата управления памятью как в 12cR1 нет, и придется делать так. На уровне ОС я HugePages сконфигурировал под 6 Гб, потом на уровне базы задал SGA auto memory management SGA_TARGET=4608M, для PGA тоже включил PGA auto memory management и выделил под нее PGA_AGGREGATE_TARGET=1536M. Тут вроде бы все под контролем, да и не о конфигурировании базы речь в этой теме :). Но когда я вижу, как на уровне ОС в таких широких пределах болтается Mem buff/cache, загоняя всю систему в своп - это удивляет, раздражает, и хочется наложить ограничения на такое поведение. И я ОС прекрасно понимаю - куда же ей деваться, если со стороны базы все жестко, и память там отобрать для текущих потребностей ОС взять нельзя. Из 8 Гб под ОС осталось 2, и если она выделила под buff/cache 1 Гб ОЗУ, а ей для запуска приложений нужно 1,5 Гб, то конечно она на 0,5 Гб уйдет в своп!

А, блин :). Только сейчас понял, что вы имели ввиду :). А что такое тогда страничный кэш?! Для чего он? Память, насколько я понял из документации на Linux, там всегда делится на страницы - 4 Кб стандартные и 2 Мб для режима HugePages. Нет, вроде как память buff/cache - это файловый кэш. По крайней мере, я так понял эту статью с RedHat, поскольку Oracle Linux - это Red Hat с переклеенной наклейкой :). Вот там даются такие слова:
"...most of the memory use is for buffers and cache. Linux always tries to use RAM to speed up disk operations by using available memory for buffers (file system metadata) and cache (pages with actual contents of files or block devices). This helps the system to run faster because disk information is already in memory which saves I/O operations. If space is needed by programs or applications like Oracle, then Linux will free up the buffers and cache to yield memory for the applications..." Вот у меня, похоже, это и происходит - перевыделив памяти под файловый кэш, Linux вынуждена его сливать на диск, уходя в своп (наверное, все же не в своп, а в дисковый ввод-вывод), для того, чтобы освбодить память для запуска приложений.

Busla 16-12-2018 13:36 2846341

GrayMagellan, можете считать меня хамом, но "Смотрю в книгу - вижу фигу":
Цитата:

Цитата GrayMagellan
cache (pages with actual contents of files or block devices »

так что кэш страничный, и следующей же главой по вашей ссылке идёт howto как им управлять :read:

GrayMagellan 17-12-2018 11:21 2846517

Цитата:

Цитата Busla
можете считать меня хамом »


Ни в коем случае! Я вам искренне благодарен. Я пришел сюда за знаниями, и буду благодарен любому, кто возьмет меня за шиворот и ткнет носом в знания :). Так что спасибо вам. Я прочитал следующую главу. Но мне непонятны следующие слова - "...To control the percentage of total memory used for page cache in Red Hat Enterprise Linux 5, change the pagecache kernel parameter...". А процент от чего контролирует этот параметр? По умолчанию 100% ("...default value of 100..."), и если следовать статье, то получается все 100% моего ОЗУ должны по умолчанию пойти под страничный кэш? Как это? Только... Я сейчас пытался посмотреть действующее значение этого параметра, и выяснилось, что у меня в Oracle Linux 7.6 (он же Red Hat 7.6) такого параметра в /proc/sys/vm/ нету :(. Отменили его в последних версиях Линукса?

Jula0071 17-12-2018 12:49 2846536

Цитата:

Цитата GrayMagellan
Из-за этого я не могу выделить памяти базе больше. »

Можете. Расценивайте buff/cache как свободную.
Цитата:

Цитата GrayMagellan
Но в мире Linux я новичок, а в "чужой монастырь со своим уставом не ходят". »

И сразу начинаете учить систему, как ей работать. :)
Цитата:

Цитата GrayMagellan
Отменили его в последних версиях Линукса? »

5-й RHEL вышел d 2007, много воды с тех пор утекло.

Если вам так уж хочется поучить систему (это иногда действительно нужно бывает в определённых ситуациях, но я не знаток Oracle и прямых рекомендаций дать не могу. разве что имхо памяти для большой БД, для чего обычно используют его, как-то уж очень мало), то можете покрутить эти гайки:
vm.swappiness – от 0 до 100, по умолчанию 60, чем выше число, тем охотнее система лезет в свап. Совсем свап выключать нельзя – чревато OOM киллами.
vm.vfs_cache_pressure – от 0 до не знаю какой величины, по умолчанию 100. Этот параметр отвечает, с какой скоростью освобождается кэш файлов/директорий. Чем больше число, тем чаще. Скажем при 1000 вместо 100 - в 10 раз чаще.
vm.dirty_background_ratio/vm.dirty_ratio - от 0 до 100, чем меньше, тем быстрее страничный кэш сбрасывается на диск.
Можете посмотреть все гайки vm.*, почитать про каждую по отдельности, покрутить, только осторожно, постепенно и при каждом изменении проводить тесты производительности и стабильности. В линуксе выстрелить себе в ногу кручением параметров ядра оч просто.

GrayMagellan 17-12-2018 15:14 2846560

Цитата:

Цитата Jula0071
И сразу начинаете учить систему, как ей работать »

Не я учу. Документация по установке и настройке базы данных Оракл 12cR2 учит. Я 12cR1 ставлю уже на автомате, и с настройкой большой памяти там нет проблем - на слое ОС создал запись в fstab под shared memory tmpfs, на слое базы выделил память (общую, а дальше база сама делит внутри этого пула её между SGA и PGA), и все пучком. Но в 12cR2 Оракл решил отказаться от Shared Memory при необходимости выделить базе много памяти, и теперь требуется настройка только под HugePages. Это оказалось труднее понять и настроить, чем в случае с Shared Memory.

Цитата:

Цитата Jula0071
памяти для большой БД, для чего обычно используют его, как-то уж очень мало »

Так это тестовая виртуалка - захочу, и после очередного ребута на ней окажется 64 Гб ОЗУ :). На уровне железа выделить X или Y ОЗУ в наше время - не проблема. Сложнее оказалось с настройкой этой памяти под софт (Oracle Database). Пока на тестовой виртуалке я использую 8 Гб ОЗУ. Для составления алгоритма выделения памяти больше, чем стандартные для Оракл Датабэйз 4 Гб ОЗУ этого количества вполне хватает. А дальше, вы сами понимаете, я в созданной инструкции только одни цифры на другие подменять буду, и всё.

С моделями памяти Linux в целом и в применении к Ораклу у меня после прочтения кучи литературы и интернета в голове уже полный хаос настал. Я уж и оракловый форум по Оракл Линукс помучал, и тех. поддержку ихнюю - нигде понятной для меня информации не получил :(. Но это в текущем контексте оффтоп.

Jula0071 17-12-2018 16:07 2846564

Цитата:

Цитата GrayMagellan
требуется настройка только под HugePages »

Про это почитайте и покрутите при надобности.
Код:

vm.hugepages_treat_as_movable = 0
vm.hugetlb_shm_group = 0
vm.nr_hugepages = 0
vm.nr_hugepages_mempolicy = 0
vm.nr_overcommit_hugepages = 0

Цитата:

Цитата GrayMagellan
Так это тестовая виртуалка - захочу, и после очередного ребута на ней окажется 64 Гб ОЗУ »

Так значит она и не отражает даже приблизительно поведения прода. Поведение кэша ооочень сильно меняется от размера доступной и реально занятой памяти, а не напугавшего вас кэша. Также латентность IO влияет очень сильно. На SSD одни настройки, на HDD другие, на iSCSI третьи, да ещё смотря по какому каналу оно ходит.
Например, если у вас мало памяти и быстрое IO – то скручивать в минимум vm.dirty полезно, если наоборот – то лучше увеличить, при этом принимая во внимание, что сбой может повлечь потерю данных. Да, всё непросто.

Busla 17-12-2018 16:33 2846567

Цитата:

Цитата GrayMagellan
то получается все 100% моего ОЗУ должны по умолчанию пойти под страничный кэш? »

не должны, а могут

Цитата:

Цитата Jula0071
Можете. Расценивайте buff/cache как свободную. »

это очень теоретическая теория - так будет только на какой-нибудь основательно затюненном чисто вычислительном сервере, который с диском вообще не работает

Jula0071 17-12-2018 17:51 2846576

Цитата:

Цитата Busla
это очень теоретическая теория - так будет только на какой-нибудь основательно затюненном чисто вычислительном сервере, который с диском вообще не работает »

И у которого 256 мегабайт рама.

GrayMagellan 17-12-2018 17:54 2846578

Цитата:

Цитата Jula0071
vm.hugetlb_shm_group = 0 »

О! Этот параметр мне уже знаком :)! Пока не указал в нем ID группы, в которую входит пользователь oracle, база отказывалась стартовать с ошибкой "ORA-27125: unable to create shared memory segment
Linux-x86_64 Error: 1: Operation not permitted" :).

Цитата:

Цитата Jula0071
vm.nr_hugepages »

Этот параметр уже тоже сконфигурирован. Вообще я после некоторых мытарств нашел онлайн-калькулятор для расчета всех этих параметров - https://www.peuss.de/node/67. Вообще там объявлено что он заточен под расчет HugePages для Java, но входных параметров всего 2 - объем одиночной HugePage страницы и сколько хотим выделить памяти под HugePage, так что я его решил использовать под расчет памяти для базы.

Jula0071 17-12-2018 17:59 2846579

Цитата:

Цитата GrayMagellan
Linux-x86_64 Error: 1: Operation not permitted »

У вас SELinux включен? Что говорит getenforce ?

GrayMagellan 17-12-2018 18:23 2846587

Цитата:

Цитата Jula0071
У вас SELinux включен? Что говорит getenforce ? »

Да эта ошибка уже не актуальна :). Я полагаю, что технические писатели документации Oracle Database просто забыли включить этот параметр в свою бумажку, ограничившись только vm.nr_hugepages.

Цитата:

Цитата Jula0071
vm.swappiness »

Интересный параметр, но, наверное, не совсем то, что мне нужно... На портале Red Hat я про него очень мало информации нашел (или она закрыта платной подпиской), но зато на форуме самого Linux мне попалась статья https://www.linux.org/threads/all-ab...71/#post-35743, в которой про swappiness говорятся такие слова:
"...The term "swappiness" refers to the likeliness of the system to use swap. This works on a scale of 0-100 where zero means indicates the swap will never be used and 100 is excessive use. Most Linux distros have a default of about "60"...". Хотя наверное этот параметр не совсем то, что мне нужно. Во-первых, я не хочу ограничивать своп, т.к. я и так ограничиваю систему по ОЗУ. Если я ограничу систему по свопу, то у нее не останется пространства для маневра памятью и она должна просто рухнуть. Во-вторых, это согласно перевода "желание" использовать операционкой своп. А мне не своп, а страничный кэш ограничить надо.

GrayMagellan 17-12-2018 18:46 2846598

Цитата:

Цитата Jula0071
Так значит она и не отражает даже приблизительно поведения прода »

Вот практически полностью не понял ваш этот пост :(. Почему не отражает? В принципе, всё это мое распределение памяти пока "по воде вилами писано", т.к. я делаю не так, как говорит Оракл. Оракл говорит "вы сначала базу разверните и запустите, а потом на рабочей нагрузке посмотрите сколько памяти вам надо выделить под HugePages". При этом для меня так и остался вопрос без ответа - по такому сценарию я сколько памяти должен выделить базе? Дефолтные 3 Гб? Но тогда это будет Automatic Memory Management, в котором я с помощью MEMORY_TARGET указываю только общий объем памяти, который выделяю базе, а границу между SGA и PGA база определяет сама. В случае же с памятью базе больше 3 Гб у меня MEMORY_MAX вместе с Automatic Memory Management отменяется, и надо делать отдельные автоматические управления областями SGA и PGA с помощью SGA_TARGET и PGA_AGGREGATE_TARGET (вариант с полностью ручным управлением памятью я даже рассматривать не хочу - на дворе 21-й век, да и нагрузка у меня точно такого тонкого тюнинга никогда не потребует). У меня сейчас база развернута, но она пустая - я ещё на ней ни одной рабочей схемы из бэкапа не поднял. Я хочу наоборот - спланировать ресурсы тестовой виртуалки под начальный объем большой памяти (8 Гб), погонять базу с рабочей нагрузкой под SGA_TARGET и PGA_AGGREGATE_TARGET, а уж потом оценивать сколько памяти докидывать на виртуалку, и потом уже подстраивать vr.nr_hugepages и прочие параметры ОС.

GrayMagellan 17-12-2018 18:50 2846599

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

RoseHill 17-12-2018 21:10 2846643

How to control the size of page cache in RHEL


How to control the size of page cache in RHEL?
Solution Проверено - Обновлено March 15 2018 at 9:32 PM - English
Окружение

Red Hat Enterprise Linux 7
Red Hat Enterprise Linux 6
Red Hat Enterprise Linux 5
Red Hat Enterprise Linux 4

Вопрос

How to control the size of the page cache in Red Hat Enterprise Linux?

Решение

In RHEL 4, 5, 6 and 7 the page cache is dynamically adjusted. There is no kernel parameter to control its size directly.

However, it is possible to indirectly influence the page cache size via tuning of the virtual memory settings.

The primary sysctl tunables (along with their default values) for controlling the behaviour of the page cache are as follows:

vm.vfs_cache_pressure (default = 100)
At the default value of vfs_cache_pressure=100 the kernel will attempt to reclaim dentries and inodes at a "fair" rate with respect to pagecache and swapcache reclaim.
Controls the tendency of the kernel to reclaim the memory which is used for caching of directory and inode objects.
Decreasing vfs_cache_pressure causes the kernel to prefer to retain dentry and inode caches. Increasing vfs_cache_pressure beyond 100 causes the kernel to prefer to reclaim dentries and inodes
To limit the size of page cache, you would want to increase this value so the kernel will be more likely to reclaim these objects.

vm.dirty_background_ratio (default = 10)
Contains, as a percentage of total system memory, the number of pages at which the pdflush background writeback daemon will start writing out dirty data.
To limit the size of page cache, decrease this number so the pdflush daemon will start writing out dirty data sooner.

vm.dirty_ratio (default = 20)
Contains (as a percentage of total system memory) the number of pages at which a process which is generating disk writes will itself start writing out dirty data.
To limit the size of page cache, decrease this number so processes will start writing out dirty data sooner.

vm.dirty_writeback_centisecs (Red Hat Enterprise Linux 4 & 5: default = 499, Red Hat Enterprise Linux 6 and 7: default = 500)
The pdflush writeback daemons will periodically wake up and write "old" data out to disk. This tunable expresses the interval between those wakeups, in 100'ths of a second. Setting this to zero disables periodic writeback altogether.
To limit the size of page cache, decrease this value so the pdflush daemon will wake up more often and write dirty data out to disk.

vm.dirty_expire_centisecs (Red Hat Enterprise Linux 4 and 5: default = 2999, Red Hat Enterprise Linux 6 and 7: default = 3000)
This tunable is used to define when dirty data is old enough to be eligible for writeout by the pdflush daemons. It is expressed in 100ths of a second. Data which has been dirty in-memory for longer than this interval will be written out next time a pdflush daemon wakes up.
To limit the size of page cache, decrease this value so data will be considered dirty sooner and will be written out by pdflush.

vm.swappiness (RHEL 5 and 6:default = 60, RHEL 7:default = 30)
This controls how likely the vm is to swap out inactive memory pages (the higher the value, the more likely it is to swap).
To limit the size of page cache, decrease this value so the kernel is less likely to swap and thus more likely to drop pages from the page cache.
A value of zero here does not prevent the system from swapping.

You do not need to reboot for sysctl changes to take effect.

Modifications to these values could effect a significant change in behavior and performance of the system (positive or negative). It is highly recommended that you modify them slightly at first and test each change thoroughly to ensure they do not have any negative effects in your environment.

For further details please check the following documents that are contained in the kernel-doc package: /usr/share/doc/kernel-doc-$VERSION/Documentation/{filesystems/proc.txt, sysctl/vm.txt}.



Цитата:

и выяснилось, что у меня в Oracle Linux 7.6 (он же Red Hat 7.6) такого параметра в /proc/sys/vm/ нету . Отменили его в последних версиях Линукса?
Это каталог, там хранятся значения ранее заданных параметров. Достаточно прочитать заголовок /etc/sysctl.conf
Скрытый текст

# sysctl settings are defined through files in
# /usr/lib/sysctl.d/, /run/sysctl.d/, and /etc/sysctl.d/.
#
# Vendors settings live in /usr/lib/sysctl.d/.
# To override a whole file, create a new file with the same in
# /etc/sysctl.d/ and put new settings there. To override
# only specific settings, add a file with a lexically later
# name in /etc/sysctl.d/ and put new settings there.
#
# For more information, see sysctl.conf(5) and sysctl.d(5).


Цитата:

На портале Red Hat я про него очень мало информации нашел (или она закрыта платной подпиской)
На портале Red Hat в тамошней базе данных об этом всём читать не перечитать. ))) Для того, чтобы читать, надо зарегистрироваться на портале разработчиков Red Hat, получить тем самым годовую бесплатную подписку и пользоваться базой "вопросов-ответов" Red Hat в полном объёме. Чтобы зарегистрироваться разработчиком на портале разработчиков Red Hat от вас требуется мыл на не публичном домене. Сгодится какой угодно уровень домена. Если у вас вдруг и неожиданно нет ни одного своего домена и даже третьего уровня, то попросите друга завести вам на время регистрации почту. Red Hat-у абсолютно безразлично сколько подписок было на один домен, допустим второго уровня, лишь бы почты были разные. Но я не думаю, что для создания почты на непубличном домене требуется помощь друга. ))

GrayMagellan 18-12-2018 17:11 2846837

Цитата:

Цитата RoseHill
How to control the size of page cache in RHEL »

О, спасибо! Очень объемлющая статья. Сижу читаю её и вникаю.

Цитата:

Цитата RoseHill
зарегистрироваться на портале разработчиков Red Hat »

О, спасибо еще раз! Я там зарегистрировался, но у меня нет подписки (платной), и потому часть статей недоступна для моего уровня доступа. Попробую сделать как вы советуете. Может, удастся получить полный доступ к базе статей по Red Hat.

Цитата:

Цитата RoseHill
мыл на не публичном домене »

Да, они отказались меня регистрировать по публичной почте, пришлось регистрироваться на рабочий ящик.

А не наступил ли у меня пипец?

AnonHugePages: 0 kB
ShmemHugePages: 0 kB
HugePages_Total: 3268
HugePages_Free: 3097
HugePages_Rsvd: 2286
HugePages_Surp: 0
Hugepagesize: 2048 kB

Если я сложу Free+Rsvd, то получится 5383 страницы. Что явно больше заданного мной 3268 шт.

Гм... Пока писал, показания стали такие:

AnonHugePages: 0 kB
ShmemHugePages: 0 kB
HugePages_Total: 3268
HugePages_Free: 816
HugePages_Rsvd: 5
HugePages_Surp: 0
Hugepagesize: 2048 kB

Вот последние цифры уже похожи на правду. Я планировал под SGA отдать 4902 Мб. Если посчитать, то получается близкая величина: (3268шт.-816шт.)*2Мб=4094Мб. Гм... Ровно на 2 Мб больше, чем я планировал. Где у меня косяк вкрался? И меня смущает, что 816 страниц болтаются во Free. За счет чего же тогда PGA взяла память?! Должна была за счет этих 816 страниц взять.

GrayMagellan 19-12-2018 16:48 2847070

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


Время: 06:02.

Время: 06:02.
© OSzone.net 2001-