Firebird увеличить память для работы

Обновлено: 03.07.2024

В Суперсервере Firebird под Windows могут быть проблемы с операционной системой, постоянно переключающей процесс Суперсервера туда и сюда между процессорами на машинах SMP. В списках поддержки это называется "эффектом качелей" и на таких системах он может оказывать сильное воздействие на производительность. Данный параметр должен быть использован для установки одного или более конкретных процессоров для Суперсервера Firebird.

Параметры CpuAffinityMask и cpu?affinity получают значение целого числа: маску CPU. Например:

Суперсервер запускается только на первом процессоре (CPU 0).

Запускается только на втором процессоре (CPU 1).

cpu_af finity = 3

Запускается на первом и на втором процессорах.

ВНИМАНИЕ! Этот параметр не работает в Windows 9х или ME, поскольку он использует вызов NT API. Версии Windows 9х не могут использовать более одного процессора.

Вычисление значения CpuAffinityMask

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

Рассматривайте центральные процессоры как массив, пронумерованный от 0 до n-1, где n- количество установленных процессоров, i - номер в массиве конкретного процессора. M- другой массив, содержащий значение маски (Maskvaiue) для каждого выбранного CPU. Значение А является суммой значений в массиве M.

Используйте следующие формулы для получения Ми вычисления Maskvaiue А:

Например, для выбора первого и четвертого процессоров (процессор 0 и процессор 3) вычислите:

А = 20 + 23 = 1 + 8 = 9

ВНИМАНИЕ! Серверы Firebird версии 1.5 и ниже могут не поддерживать Нурег-Threading на некоторых ранних моделях материнских плат. Для устранения проблем балансировки нагрузки может оказаться необходимым отменить Hyper-Threading на уровне BIOS системы.

Маска процессоров по умолчанию 1 (процессор 0).

Версия 1.5 и более поздние.

Версии, предшествующие Firebird 1.5.

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

Значение по умолчанию для Суперсервера 2048 страниц. Для Классического сервера - 75.

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

Версия 1.5 и более поздние.

Это целое число, задающее количество байтов памяти, выделяемой для менеджера событий. Значение по умолчанию 65 536 (64 Кбайт).

Версия 1.5 и более поздние.

Этот параметр позволяет сконфигурировать размер в байтах каждого блока памяти, используемого для модуля внутренней сортировки. Значение по умолчанию при инсталляции 1 Мбайт, который вы можете заменить любым значением, не превышающим текущее значение максимума, установленного в параметре sortMemupperLimit.

Версия 1.5 и более поздние.

Максимальный размер памяти в байтах, выделяемой для модуля внутренней сортировки. Значение по умолчанию при инсталляции 67 108 864 байт (64 Кбайт) для Суперсервера и 8 388 608 байт (8 Кбайт) для Классического сервера.

ВНИМАНИЕ! Для Классического сервера значение по умолчанию слишком велико, если только не подключено большое количество клиентов. Помните, что увеличение размера любого блока или максимального ограничения в Классическом сервере влияет на каждое клиентское соединение (экземпляр сервера) и увеличивает потребление сервером памяти в линейной пропорции.

Работа с ресурсами локальной сети

Работа с ресурсами локальной сети Стандартным объектом, позволяющим выполнять типовые операции с локальной сетью, является WshNetwork. С помощью этого объекта можно:? узнать сетевое имя компьютера, имя текущего пользователя и название домена, в котором он

27.5. Параметры транзитных узлов и параметры получателя IPv6

27.5. Параметры транзитных узлов и параметры получателя IPv6 Параметры для транзитных узлов и параметры получателя IPv6 имеют одинаковый формат, показанный на рис. 27.3. Восьмиразрядное поле следующий заголовок (next header) идентифицирует следующий заголовок, который следует за

8.6. Управление ресурсами

8.6. Управление ресурсами В этом разделе мы рассмотрим только один аспект управления ресурсами: как сэкономить тот или иной ресурс, точнее, как поступить в случае, если какого-то ресурса недостаточно. Основными ресурсами компьютера являются память и дисковое пространство.

1.7.4 Связанные документы

1.7.4 Связанные документы Серия RFC не содержит спецификаций протоколов и была опубликована как отдельный набор документов For Your Information (FYI — К вашему сведению). Например: RFC 1325 Answers to commonly asked "new Internet user" questions (Ответы на наиболее распространенные вопросы новых пользователей

Взаимодействие с тематически близкими ресурсами

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

Связанные документы

Связанные документы В последних версиях Windows появилось понятие сопоставленных файлов. Например, если вы собираетесь переместить или удалить html-документ, то будут также перемещены или удалены и сопоставленные с этим документом файлы, которые содержаться в папке

Управление ресурсами

Управление ресурсами Еще одна проблема поддержки нескольких интерфейсов из одного объекта становится яснее, если исследовать схему использования клиентом метода DynamicCast. Рассмотрим следующую клиентскую программу:void f(void)

Управление ресурсами и IUnknown

Управление ресурсами и IUnknown Как было в случае с DuplicatePointer и DestroyPointer из предыдущей главы, методы AddRef и Release из IUnknown имеют очень простой протокол, которого должны придерживаться все, кто пользуется указателями этих интерфейсов. Эти правила освобождают клиента от

Связанные файлы

Связанные файлы В связи с тем что в профессиональной графике файлы изображений могут достигать большого размера – действительно большого, десятки и сотни мегабайт, – многие программы макетирования и верстки не включают файлы изображений в документ. Так поступает и

Глава 3 Управление ресурсами

Глава 3 Управление ресурсами Ресурс – это нечто такое, что после использования должно быть возвращено системе. Если этого не сделать, случаются неприятности. В программах на C++ наиболее часто используемым ресурсом является динамическая память (если вы выделяете память и

Правило 13: Используйте объекты для управления ресурсами

Правило 13: Используйте объекты для управления ресурсами Предположим, что мы работаем с библиотекой, моделирующей инвестиции (то есть акции, облигации и т. п.), и классы, представляющие разные виды инвестиций, наследуются от корневого класса Investment:class Investment <. >// корневой

Правило 14: Тщательно продумывайте поведение при копировании классов, управляющих ресурсами

Правило 14: Тщательно продумывайте поведение при копировании классов, управляющих ресурсами В правиле 13 изложена идея Получение Ресурса Есть Инициализация (Resource Acquisition Is Initialization – RAII), лежащая в основе создания управляющих ресурсами классов. Было также показано, как эта

8.3. Использование конструкторов и деструкторов для управления ресурсами (RAII)

8.3. Использование конструкторов и деструкторов для управления ресурсами (RAII) ПроблемаДля класса, представляющего некоторый ресурс, требуется использовать конструктор для получения этого ресурса и деструктор для его освобождения. Эта методика часто называется

7.3.2. Параметры-ссылки и параметры-указатели

7.3.2. Параметры-ссылки и параметры-указатели Когда же лучше использовать параметры-ссылки, а когда – параметры-указатели? В конце концов, и те и другие позволяют функции модифицировать объекты, эффективно передавать в функцию большие объекты типа класса. Что выбрать:

Параметры, связанные с коммуникацией

Параметры, связанные с коммуникацией ConnectionTimeoutВерсия 1.5 и более поздние.connection_timeoutВерсии, предшествующие Firebird 1.5.Задает количество секунд ожидания до прекращения попытки соединения. Значение по умолчанию 180.DummyPacketlntervalВерсия 1.5 и более поздние.dummy_packet_intervalВерсии,

48 Связанные объекты

48 Связанные объекты Что делает тот или иной предмет легким для понимания? Что делает тот или иной предмет простым в использовании? Что превращает совокупность объектов — не отдельных, а представленных в определенном контексте — в набор рабочих инструментов? Возьмем

Firebird является очень популярной открытой СУБД в России, и, несмотря на отсутствие шумных маркетинговых акций, используется в большом количестве ответственных систем, особенно в медицинских и государственных системах автоматизации.

Размер БД и количество активных пользователей в таких системах обычно достаточно большие, поэтому в этой статье я расскажу об опыте оптимизации настроек Firebird и Linux, основываясь на конкретных примерах больших БД Firebird в компаниях БудьЗдоров (Ингосстрах), АльфаЗдрав, и затрону опыт других компаний по оптимизации Firebird+Linux.

Давайте подробнее познакомимся с предметом оптимизации — СУБД Firebird 3.0.5 (с расширениями HQbird), обслуживает БД размером 691Гб (на текущий момент) с ежедневными 1000-1100 пользователями, работает на Linux CentOS 7, сервер — железный HP DL380. Для БД настроена репликация на резервный сервер (вопрос о репликации вне рамок этой статьи).

СУБД обслуживает медицинскую информационную систему Инфоклиника (производства российской компании Smart Delta Systems), которая является одной из самых популярных медицинских информационных систем в России.

Давайте взглянем на подробности (скриншоты далее взяты из HQbird) работы этой базы данных:

Данные интенсивно вставляются в БД — ежедневный прирост около 0.4 — 0.5 Гб

1000-1100 соединений это обычная дневная нагрузка:

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

Маркеры транзакций в «зеленой» зоне:

Кстати, обратите внимание, что данные в БД — строковые, блобы присутствуют, но их мало — всего 10Гб из 690Гб общего размера.

Характер нагрузки на БД смешанный, 75% операций чтения и 25% записи:

Железо

Сервер, который обслуживает эту систему, неплохой, но далеко не топовый:

Дисковая подсистема состоит из двух частей: локальный диск на 745Gb и двойной 2 fibre-channel connection к SAN, с разделом на 1.8Тб.

Операционная система

Используется CentOS 7, версия ядра:

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

Однако, надо отметить, что до 2017 года система работала на CentOS 6.x, и после миграции было отмечено значительное улучшение показателей производительности.

Настройка Linux

Абсолютно необходимая настройка Linux для Firebird

Есть 2 параметра, которые нужно обязательно увеличить на всех серверах Linux, где работает Firebird — число виртуальных областей памяти (virtual memory areas, VMA) и число открытых файлов для процесса Firebird.

Число VMA по умолчанию 64K, его необходимо увеличить в 4 раза, для этого в sysctl.conf надо добавить строку

Чтобы проверить текущее значение, используйте команду

2. Max Open Files

На каждое соединение к БД Firebird открывает до 20 описателей (файловых хэндлов) включительно (учитывая тот факт, что в Linux все ресурсы выглядят как файлы), поэтому максимальное количество открытых файлов по умолчанию (обычно 4096) может очень быстро исчерпаться.

Чтобы проверить доступное количество файлов для Firebird, лучше всего посмотреть лимиты исполняемого файла Firebird:

где проверить значение для Max Open Files и увеличить их при необходимости.

Чтобы увеличить параметр Max Open Files для Firebird, в файл firebird-superserver.service в секцию [service] мы добавили строку:

Опциональная настройка Linux

На этом сервере мы также сделали следующие настройки

1. Уменьшили swapiness

Так как сервер является выделенным эксклюзивно для СУБД Firebird, и мы желаем эффективно использовать RAM под кэш СУБД и кэш файлов операционной системы, то уменьшаем swapiness c дефолтных 60% до 10%, для этого в sysctl.conf добавили

2. Увеличили минимальный зарезервированный размер памяти для специальных процессов ОС

т. е. 1Гб памяти. Эта настройка косвенно влияет на дефрагментацию памяти.

Обратите внимание, что эта настройка индивидуальна — с учетом того, что у нас 320Гб RAM, 1Гб это не так уж и много, но в случае небольшого количества памяти (например, 32Гб), 1Гб мог бы быть перебором.

3. Уменьшили keepalive

Firebird полагается на keepalive интервалы, чтобы проверять состояние соединения, и по умолчанию значение keepalive может быть очень большим. Ограничивая его до 300 секунд, мы избавляемся от зависших соединений

Еще больше тюнинга Linux

Почему мы ограничились таким небольшим количество настроек Linux?

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

Конечно, существует еще несколько настроек, которые можно использовать для оптимизации работы Firebird на Linux — например, ряд интересных вещей был представлен в презентации о 3 Тб базе данных Firebird (РедБаза) в Федеральной Службе Приставов.

Настройка Firebird

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

Ниже приведены конфигурационные файлы (только значения, относящиеся к производительности):

firebird.conf — конфигурационный файл для всех БД на сервере

С точки зрения производительности, ключевыми параметрами здесь являются следующие:

Размер страничного кэша DefaultDbCachePages в firebird.conf специально установлен по умолчанию в 800Mb — для того, чтобы случайно затесавшаяся на сервере тестовая БД не попыталась занять огромное количество оперативной памяти.

Важно устанавливать этот параметр в значение большее, чем DefaultDBCachePages, чтобы разрешить использование файлового кэша ОС.

Это параметр устанавливает размер памяти для запросов с сортировками (и некоторыми другими операциями), и является индивидуальным для каждой системы.
В результате мониторинга размеров сортировок мы выяснили, что 20Гб является оптимальным для данной БД.

4. LockMemSize и LockHashSlots — параметры таблицы блокировок

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

5. WireCompression=True

Настройка сжимает трафик между клиентами и серверов, особенно это полезно при интенсивных Execute Statement On External, которые выполняет клиентское приложение.

Остальные параметры описаны в самом firebird.conf и сопутствующей документации Firebird и HQbird.

Наиболее важные настройки мы вынесли в databases.conf, с точным указанием БД

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

Для Firebird 3.0 c архитектурой SuperServer существует два подхода — консервативный, который используется на серверах с небольшим количеством оперативной памяти (до 32Гб включительно), который заключается в том, чтобы выделять под страничный кэш не более 25% RAM, и в остальном полагаться на файловый операционной системы, и тонкая настройка, когда мы точно определяем оптимальный размер для сортировок, выделяем определенный размер памяти для ядра ОС, резервируем определенный объем памяти для массивных файловых операций (например, резервное копирование), и остаток выделяем на страничный кэш.

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

Типичные ошибки в настройке Firebird

К типичным ошибкам относятся следующие:

1) Явно указанный на странице заголовка БД размер страничного кэша, который переопределяет значения, указанные в firebird.conf и databases.conf.

Особенно часто эта ошибка возникает при смене архитектуры с Classic/SuperClassic на SuperServer — если при явно указанном небольшом (500-2000 страниц) размере кэша на соединение Classic/SuperClassic работают нормально, то для SuperServer необходим гораздо больший кэш.
Чтобы проверить, выполните команду

и проверьте значение Page Buffers — оно должно быть равно 0, тогда Firebird будет использовать значения из databases.conf или firebird.conf.

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

2) При увеличении страничного кэша забывают увеличить FileSystemCacheThreshold, что ведет к отключению файлового кэша, что снижает производительность.

3) Использование размера страницы БД по умолчанию (4096 или 8192), в то время как для больших БД необходимо использовать 16К.

Заключение

В целом, 1000+ пользователей Firebird на железе, соответствующем нагрузке, настроенном Linux и сконфигурированном Firebird, работают без проблем. На данном сервере по производительности есть запас, который был протестирован в пиках нагрузки до 1500-1800 пользователей.

Среди Linux-дистрибутивов для БД Firebird c подобной нагрузкой наиболее популярен CentOS 7, рекомендуемая версия — Firebird 3.0.

У системных администраторов часто возникают два вопроса относительно использования оперативной памяти сервером Firebird:

Сколько памяти следует установить для комфортной работы сервера базы данных?
Почему при нагруженном сервере менеджер задач показывает относительно небольшое использование памяти процессами Firebird?

Попробуем ответить на оба.

Оперативная память сервера распределяется для:

Программного кода, стека и данных ядра операционной системы. По нашим наблюдениям операционная система Windows Server 2003 требует "для себя" порядка 0.5 Гб. Можно предположить, что требования Windows Server 2008 будут еще выше.
Выполняющихся на сервере приложений и служб.[1]
Дискового кэша.
Сервера баз данных Firebird.

Каждый серверный процесс Firebird архитектуры Super [2] или Classic использует следующее количество памяти:

Зависимость производительности сервера Firebird от размера кэша операционной системы

При считывании данных Firebird сначала пытается найти нужные страницы в своем кэше. Если их там нет -- обращается к операционной системе. Операционная система, в свою очередь, проверяет нет ли нужных данных в ее кэше и только потом начинает операцию чтения с дискового устройства. При использовании сервера классической архитектуры, размер буфера каждого серверного процесса устанавливается небольшим (обычно 800-1000 страниц). Таким образом, производительность Firebird будет в большей степени определяться размером дискового кэша операционной системы. То же верно и для архитектуры SuperServer, когда размер базы данных намного превышает размер выделенного буфера.

При использовании 32-х разрядной операционной системы размер файлового кэша ограничен 1-1.5 Гб. Практического ограничения нет при использовании 64-х разрядной ОС. При этом стоит учитывать, что только начиная с Windows 7 и Windows Server 2008 R2 решена проблема с поглощением файловым кэшем всей доступной оперативной памяти и вытеснением памяти других процессов в своп [3] .

Использование кэша операционной системы для размещения файлов сортировки

По полю description в базе данных индекса нет, а это значит что будет создан файл сортировки. В него будут выгружены все значения поля description из всех строк таблицы gd_document. Не важно, что в подавляющем большинстве записей оно пустое. Данное поле имеет тип VARCHAR (180), однобайтовая кодировка Win1251.

Мы провели тест на одной из рабочих баз:

Версия сервера: Firebird 2.5 RC3
Выполняемый запрос: SELECT description FROM gd_document ORDER BY 1
Количество записей в gd_document: 31 808 358
Тип поля description: VARCHAR (180), однобайтовая кодировка
Размер данных в поле description: 11 376 340 байт
Размер файла сортировки: 18 210 586 624 байт
Время выполнения запроса:

Размер данных определялся запросом:

Таким образом, в нашем примере на каждый миллион записей в исходной таблице файл сортировки увеличивался почти на 600 Мб.

Информацию по структуре и размеру файла сортировки можно получить на форумах поддержки Firebird. Приводим цитаты разработчиков сервера Дмитрия Еманова и Влада Хорсуна:

В запись сортировки попадает декларированная длина поля, выровненная до 4-х байтной границы, плюс служебная информация (как минимум номера записи и транзакции).
<. >
любая INTL-строка дважды кладется в сортировщик, первый раз как ключ (преобразованная по collate), а второй раз как данные (as is), чтобы именно ее и вернуть при фетче из сортировщика. Ведь преобразование из ключа в строку в общем случае неоднозначно, а саму запись мы после сортировки уже не читаем.
<. >
Если Collate у столбца словарный (PXW_CYRL и т.п.), то храним два байта на символ.

Операционная система Windows ведет себя следующим образом: если оперативной памяти достаточно, то временный файл удерживается в памяти. Физической записи на диск не происходит. Следует обратить внимание, что память, используемая под временные файлы сортировки, не отображается в Task Manager. Поэтому, если Task Manager при подключенных пользователях показывает общее использование памяти 40-60%, это еще не значит, что памяти достаточно и расширять ее не имеет смысла.

Папки для размещения временных файлов определяются параметром TempDirectories в файле конфигурации firebird.conf. Если он не задан (по умолчанию), используются пути прописанные в переменных окружения FIREBIRD_TMP, TEMP, TMP.

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

Пример расчета потребности в памяти для сервера архитектуры Classic

Размер базы данных: 10 Гб
Планируемое количество подключений: 70
Размер страницы: 8192 байт
Размер буфера: 1000 страниц
Параметры по умолчанию в файле конфигурации

Память под процессы:

Память под собственные нужды ОС [4] :

Память под файлы сортировки [5] :

Память под дисковый кэш:

Таким образом, получаем:

Вы бы хотя бы указали какой тип IB/FB сервера используете (Classic или Super) и конфигурацию железа (кол-во памяти и процессоров и дисковую подситему).
А так же тип нагрузки, размер файла базы и кол-во народа работающего с базой.

поиск - здесь на форуме по слову "*nterbase"

Читал я эту ветку. Получается, что вы только поменяли Super на Classic? Расписывать конфигурацию не стал из-за того, что меня не интересует вопрос общей производительности, у меня конкретный вопрос про память. И хотелось бы услышать что-то типа: "Для решения данной проблемы надо установить значение параметра DefaultDBCachePages равным 8000".
Ну если это поможет, то опишу конфигурацию:
в качестве сервера используется обычный комп P4-3.0 с гипертрейдингом, 1Гб, SATA RAID1 120*2, база 1,4Гб, пользователей примерно 10, активно используют информацию примерно 4. Режим, видимо, Super, установка происходила со значениями по умолчанию.
Сервер в ближайшее время будем менять, но на старом хочется определить - в чем причина тормозов. Да, мы просто перешли на классик сервер, производительность для одного человека изменилась незначительно, но исчезли ожидания окончания запросов (или тем более тяжёлых отчётов) от других коллег

Я бы отключил гипертрейдинг.

Оценивать только Memory Page глупо. Надо оценивать его в комплексе с другими показателями.

Я прочитал ваш топик за 2003 год, как вы просто перешли на классик и получили прирост.

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

Суперсервер основан на нитях. Классик - на отдельных процессах.

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

Если вы перешли с нитей на процессы и получили прирост, то это говорит только о кривизне реализации нитей в конкретной ОС, а не о общей тенденции.

Кривизну реализацией нитей в Линуксе признавали сами разработчики ядра. Именно поэтому разворачиваются страсти вокруг NPTL, LinuxThreads, NPGT и прочее.

Приходит к Горбачеву министр сельского хозяйства и говорит:
- Михаил Сергеевич, куры дохнут, не знаем, что делать.
- А давайте нарисуем перед каждой курицей черный квадрат. Я думаю, с психологической точки зрения это поможет ей раскрепоститься. . .
Нарисовали. Через неделю министр приходит опять:
- Михаил Сергеевич, половина всех кур сдохла. Что делать?
- А давайте в черный квадрат впишем желтый треугольник.
Вписали. Проходит неделя, приходит министр.
- Михаил Сергеевич, кур только на развод осталось!
- А давайте подойдем к вопросу конструктивно и опишем вокруг каждого квадрата красный круг. . .
Описали, благо кур осталось немного. Через неделю:
- Михаил Сергеевич, я решил уйти на пенсию. Все куры сдохли.
- Эх, жаль! У меня было еще столько много новых идей!
and3008 писал(а): Оценивать только Memory Page глупо. Надо оценивать его в комплексе с другими показателями. А кидаться общими ссылками, не читая вопросов, не зная конкретного ответа, это умно? Я же писал: "Посмотрел счетчики, вроде все нормально, за исключением Memory / Page/sec". Если знаете, какие показатели надо надо посмотреть и какие значения у них должны быть - пишите!

Странная логика - искать проблемы у FireBird по доке от MS SQL.
Вы искали проблему на уровне ОС, вам и была дана дока, поволяющая более правильно проводить оценку результатов.

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

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

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

Я прочитал ваш топик за 2003 год, как вы просто перешли на классик и получили прирост.

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

Суперсервер основан на нитях. Классик - на отдельных процессах.

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

Вы рассуждаете очень здравомысляще, с замахом на глубокое знание кода ядра линукса
вот только слона не замечаете.
всё очень просто - суперсервер не поддерживает SMP и с учётом того что нагрузку создаёт не один пользователь мы и получаем увеличение быстродействия (точнее это ускорение реакции системы вцелом, скорось обработки отдельных запросов конечно же не меняется.) and3008 писал(а): Странная логика - искать проблемы у FireBird по доке от MS SQL.
Вы искали проблему на уровне ОС, вам и была дана дока, поволяющая более правильно проводить оценку результатов.
. Прежде чем что-то писать, по ссылке-то надо было зайти! Там описание тех же счетчиков плюс счетчики SQL. Просто это все не такое древнее, как в вашей покрывшейся плесенью ссылке. and3008 писал(а): Если вы считаете, что кто-то из здешних даст ответ точный, полный и исчерпывающий - успокойтесь. Никто этого делать не будет.
Вы попутали тех.суппорт, который за бабки, и форум, который за спасибо. Не надо только меня учить, что такое форум, знаем плавали, и здесь мне вполне конкретные ответы давали. Если вы никому никогда за бесплатно советы не даете, ну и не фиг чушь всякую писать! and3008 писал(а): Желаете решить свою проблему посредством форума - ведите диалог с отвечающими, засунув свое раздражение в известное место. Люди, которые вам ответили уже проявили к вам внимание, цените это. Нормальных людей я ценю, ну а таким кадрам всегда найду что ответить, чтобы впредь неповадно было. and3008 писал(а): Например чтобы дать вам более полный совет по решению вашей проблемы мне не хватает информации о производительности системы. Упомянутый вам счетчик ничего существенного не дает пока не дает. Его значение начинает играть значение вкупе с другими счетчиками.

"не дает пока не дает", "значение начинает играть значение" - заикаетесь что-ли? Ну не надо так нервничать, все нормально!

Вопрос совсем простой был: "Как заставить FireBird использовать больше оперативной памяти, а не тусовать с диска в память, из памяти на диск 20Мб?" С SQL я больше работал, знаю, как его заставить всю память съесть, вот и думал, что кто-нибудь расскажет.
А вышла из этого хрень какая-то. (

Читайте также: