В версии 3.0 были реализованы существенные изменения для повышения отказоустойчивости и стабильности. На данной странице приводится обзор этих изменений и их описание. Дополнительную информацию можно найти в других разделах справки.
| Изменение | Описание |
| Контроль перегрузки для драйверов | Контроль перегрузки предотвращает нестабильность работы всей системы, вызванную драйвером, создающим данные быстрее, чем их может обработать система. Как правило, выходная очередь к менеджеру событий увеличивается до тех пор, пока не будет израсходована вся память (драйвер создает данные быстрее, чем менеджер данных может их обработать). Для предотвращения перегрузки менеджер событий должен квитировать сообщения с новыми значениями, а выходная очередь ограничена параметром «maxOutputQueueSize» в секции [driver] конфигурационного файла config. Данный параметр определяет предельное количество записей (изменений значений) в очереди (одна запись на каждое изменение элемента точки данных). Когда количество изменений значений превысит указанное предельное количество записей, сообщения будут перемещены во вторую очередь (= очередь перегрузки). Данные одного и того же элемента точки данных (DPE) в данной очереди будут перезаписываться поверх старых. Это означает, что длина очереди не сможет произвольно увеличиваться. После освобождения первой очереди данные из очереди перегрузки перемещаются в первую очередь, и перезапись данных прекращается. Для аналоговых значений перезапись приводит к потере данных. Изменения цифровых значений (например, изменения 0-1) в очереди перегрузки сохраняются без перезаписи. Драйвер может отправлять определенное количество сообщений заранее без ожидания их квитирования. Данный параметр может быть настроен при помощи записи «commitCount» в конфигурационном файле config. Например, если параметр commitCount имеет значение 10, то драйвер может отправить 10 значений, а затем должен ожидать квитирования первого сообщения. Дополнительные главы: конфигурационный файл – секция [driver] |
| Контейнер очереди сообщений в менеджере событий (в направлении приема) | При помощи записей «maxInputMsgCount» и «msgQueueLimitTimeout» в секции [event] имеется возможность задать пороговое количество сообщений в очереди и длительность таймаута (время, в течение которого допускается превышение порога). Если количество сообщений все еще превышает порог после истечения таймаута, то далее обработка производится в аварийном режиме. В чрезвычайном режиме прекращается работа подключения с определенным менеджером, но не в случае с менеджером данных или менеджером событий (менеджер событий прекращает работу подключения, что приводит к прекращению работы самого менеджера). Дополнительные главы: конфигурационный файл – секция [event] |
| Выходная очередь ВСМ во всех менеджерах (в направлении отправки) | При помощи записей «maxBcmBufferSize» и «bcmBufferLimitTimeout» в разделе [general] имеется возможность задать пороговый размер выходной очереди ВСМ и длительность таймаута (времени, в течение которого допускается превышение порогового значения). Если пороговый размер все еще превышен после истечения срока таймаута, то далее обработка производится в аварийном режиме. В аварийном режиме подключение к соответствующему менеджеру закрывается (за исключением менеджера данных или менеджера событий (если менеджер событий закрывает подключение, то прекращается работа самого менеджера)). Дополнительные главы: конфигурационный файл – секция [general] |
| Ограничение по времени для запросов менеджера событий | Для предотвращения полной блокировки менеджера событий в процессе обработки запросов, с помощью записи «maxParseTime» можно задать время обработки запросов (в менеджере событий). Дополнительные главы: конфигурационный файл – секция [event] |
| Ограничение в менеджере событий размера запроса со значениями | Запросы исторических данных, запрашивающие количество элементов, превышающее максимальное заданное количество (количество строк х количество столбцов), будут отклоняться как можно раньше, при этом будет сгенерировано сообщение об ошибке. (Максимальное количество запрашиваемых элементов настраивается при помощи записей «maxValueRequestCount» для запроса dpQuery() и «maxValueConnectCount» для запроса dpQueryConnect() в секции [event] конфигурационного файла config). Дополнительные главы: конфигурационный файл – секция [event] |
| Ограничение в менеджере событий размера запроса с алармами. | Исторические запросы, запрашивающие количество элементов, превышающее максимальное заданное количество (количество строк х количество столбцов), будут отклоняться как можно раньше, при этом будет сгенерировано сообщение об ошибке. (Максимальное количество запрашиваемых элементов настраивается при помощи записей «maxAlertRequestCount» для запроса dpQuery() и «maxValueConnectCount» для запроса dpQueryConnect() в секции [event] конфигурационного файла config). Дополнительные главы: конфигурационный файл – секция [event] |
| Ограничение в менеджере данных размера запроса со значениями | Запросы исторических данных, запрашивающие количество элементов, превышающее максимальное заданное количество (количество строк х количество столбцов) будут отклоняться как можно раньше, при этом будет сгенерировано сообщение об ошибке. (Максимальное количество запрашиваемых элементов настраивается при помощи параметра «maxValueRequestCount» в секции [data] конфигурационного файла config). Это действительно для запросов dpGetPeriod() и dpQuery(). Ограничение также может быть задано во внутренней точке данных «_Config.MaxValueRequestCount» (если DPE = -1, то действует значение по умолчанию = 1000000 элементов, 0 = без ограничений). Дополнительные главы: конфигурационный файл – секция [data] |
| Ограничение в менеджере данных размера запроса с алармами | Исторические запросы, запрашивающие количество элементов, превышающее максимальное заданное количество (количество строк х количество столбцов), будут отклоняться как можно раньше, при этом будет сгенерировано сообщение об ошибке. (Максимальное количество запрашиваемых элементов настраивается при помощи параметра «maxAlertRequestCount» в секции [data] конфигурационного файла config). Это действительно для запросов с alertGetPeriod(), dpQuery() и OLE DB. Ограничение также может быть задано во внутренней точке данных «_Config.MaxAlertRequestCount» (если DPE = -1, то действует значение по умолчанию = 1000000 элементов, 0 = без ограничений). Дополнительные главы: конфигурационный файл – секция [data] |
| Ограничение размера запроса значений из исторической БД. | Запросы исторических значений, запрашивающие из одного или более архивов исторической БД количество строк, превышающее заданное максимальное количество запрашиваемых строк, будут отклоняться как можно раньше, при этом генерируется сообщение об ошибке. (Максимальное количество запрашиваемых строк и таймаут настраиваются при помощи параметров «queryTimeout» и «queryMaxValues» в секции [valarch] конфигурационного файла config). Это действительно для запросов с dpGetPeriod(), dpQuery() и OLE DB.Дополнительные главы: конфигурационный файл – секция [valarch] |
| Расчет статистических функций | Если менеджер событий не справляется со своевременным расчетом статистических функций (например, вследствие перегрузки), более давние периоды в буфере, начиная с задержки в n интервалов (вне зависимости от времени задержки!), будут отброшены, при этом будет отображено соответствующее сообщение и будет рассчитан последний интервал n.Значение n можно указать в записи «statFctMaxIntervalsInPast» конфигурационного файла config (значение по умолчанию: 3). Учитываться будут 3 интервала (интервал, начинающийся с конца интервала и до текущего момента). Это также относится к функциям с задержкой в расчетах. Они должны быть выполнены в течение трех периодов, иначе пропущенные периоды будут отброшены.Дополнительные главы: конфигурационный файл – статистические функции |
| Проверка релевантности сообщений | Каждое событие в менеджере «КАСКАД Цифра» содержит заголовок, являющийся идентификатором сообщения. Попытки подключения, исходящие от каких-либо сторон, не являющихся менеджерами «КАСКАД Цифра» (например, сканеры портов, Telnet), будут немедленно отклоняться. |
| Обработчик ошибок | Многочисленные повторные сообщения об одной и той же ошибке отбрасываются. В результате происходит уменьшение интенсивности непродуктивного потока сообщений (средство просмотра журналов). |