Высокая загрузка памяти с firebird + windows server 2008 r2
mfinni находится так на деньгах с этим - это действительно зависит.
ЕСЛИ Вы свяжетесь со многими cloud-storage/CDN поставщиками и конкретно спросите их, если они могут взять Ваше содержание, копировать его глобально и гарантировать, что это глобально load-balanced/delivered Вашим пользователям от их самой близкой точки репликации не, только будет некоторые из них мочь сделать это, но и они пожмут Вашу руку очень тепло действительно, потому что они будут делать много денег от Вас для этого - это ОЧЕНЬ дорого для Вас, если Вы хотите, чтобы это произошло, но они сделают это для Вас, если Вы спросите.
Теперь то, что я думаю, что Вы хотите знать, является желанием копирование Ваших данных, поскольку mfinni говорит, что 'это зависит' на поставщике и пакете, который Вы выбираете; будет это быть глобальным, тот же ответ; они поставят его оттуда, почти наверняка не по умолчанию, но 'это зависит' от пакета, который Вы оплачиваете - в основном слушают mfinni и говорят с различными поставщиками.
Ну, в конце концов, проблема решена. это было немного настройки Windows и немного настройки Firebird.
Что касается Windows, setcache действительно помогал контролировать размер кеша файловой системы, даже когда Microsoft говорила, что мне это не понадобится . Я только что добавил задачу расписания для запуска при каждой загрузке.
но даже после уменьшения использования памяти моя база данных firebird все еще использовала 12,5% моего двухъядерного четырехъядерного процессора: 100% одного ядра, и производительность была ужасной (30 секунд, чтобы выбрать все кортежи из таблицы, содержащей всего 10 кортежей).
после некоторого мониторинга с помощью sinática (www.sinatica.com) я понял, что моя база данных быстро растёт. поэтому я отключил автоматическое сканирование и добавил еще одну задачу расписания, чтобы выполнять сканирование на двухдневной основе.
Похоже, это поможет вам двигаться в правильном направлении - http://www.firebirdfaq.org/faq333/ .
Вот обновление по проблеме (надеюсь, полезно):
http://dyemanov.blogspot.com.br/2012/03/firebird-vs-windows-file-system- caching.html
Таким образом, кажется, что единственным эффективным решением является отключение запроса произвольного доступа (т.е. удаление флага FILE_FLAG_RANDOM_ACCESS) из вызовов Windows API, используемых для создания / открытия файлов. Более того, в этом случае ограничение на размер кэша файловой системы больше не должно быть актуальным, поскольку Windows не будет расширять кеш за разумные границы.
...
это решение было перенесено в Firebird 2.1 .5, Firebird 2.5.2 и Firebird 3.0 ветки.
Эта проблема может быть устранена с помощью инструмента Microsoft DynCache. Это обходное решение применимо, если вы не можете изменить сервер FireBird на версию, которая не имеет кэш-памяти, например, при использовании программного обеспечения, которое требует прерванную версию, или подобное.
Поскольку DynCache довольно сложно приобрести и правильно настроить, смотрите инструкции по его использованию здесь: http://sqlblogcasts.com/blogs/grumpyolddba/archive/2009/03/18/x64-memory-problems.aspx