Что значит параметры сервера

Как правильно подобрать параметры для выделенного сервера

В предыдущей статье «Варианты размещения ИТ-инфраструктуры. Локальный сервер против сервера размещенного в Дата-центре» мы рассказали, где и как размещать 1С, и что лучше: разворачивать свою инфраструктуру или воспользоваться арендой выделенного сервера для 1С. В этой же статье копнем глубже, к корням. Расскажем, чем мы руководствуемся, когда предлагаем модель арендуемой инфраструктуры. Ответим на вопрос: Какие параметры важны персональному ІТ-инженеру, чтобы подобрать и развернуть выделенную инфраструктуру под особенности Заказчика?

Наше кредо: «Дай клиенту не минимум, а оптимум»

Комфортная работа на выделенном сервере под 1С, как правило, на 50% зависит от правильно подобранных ресурсов. Если предоставить мало ресурсов, то это скажется «торможением» в работе, а чрезмерно «раздутый» сервер, «влетит» в немалую копейку.

Примечание 1. Часто предприниматели пытаются сэкономить на ресурсах копейки, а нам приходится чуть ли не с кулаками доказывать: «Андрей Николаевич, доверьтесь нашему опыту. Вам нужно именно 20Гб ОЗУ и 30Гб диска. Нельзя использовать 14Гб ОЗУ или впритык арендовать под 1С только 23Гб диска без запаса».

У IT-департамента есть алгоритм подбора оптимальных ресурсов. Он выглядит как опросный лист. По результатам его заполнения мы подбираем оптимальные ресурсы для виртуального сервера 1С с максимальным КПД. Что в нем написано? А вот что:

Какое количество пользователей будет работать в системе и с 1С.

Какой общий объем баз 1С и дополнительных файлов.

Платформенность баз 1С (7.7 или 8.2/8.3, возможно и обе).

Какую операционную систему предпочитает клиент.

Необходимо ли разворачивать сервер баз данных (MS SQL Server)?

Предпочтительный режим работы с 1С (тонкий клиент, работа в режиме Remote Desktop).

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

Какое дополнительно программное обеспечение необходимо установить?

Вообще, есть минимальные требования к инфраструктуре заказчика:

Операционная система – не ниже Windows Vista/7/8/8.1/10.

Наличие Microsoft.Net Framework версии Framework 4.5.

Стабильный интернет–канал со скоростью не ниже 128 Кбит/с.

Что касается «начинки» сервера, то для определения оптимального объема ОЗУ, количества ядер и других характеристик процессора есть свои правила. Вот они.

Параметр 1. Ядра

Как когда-то сказал один из философов: «Без ядра орех ничто, также, как и человек без сердца». Он как в воду глядел, ведь для сервера «ядерность» – очень важный показатель. Поэтому важно правильно рассчитать их количество. Например, для выделенного сервера 1С под 10 пользователей верным можно считать расчет:

∑ядер = 2 (для операционной системы) + 2 (для SQL сервера) + 1 (для сервера приложений) + 1 (для обеспечения одновременной работы 10 пользователей) = 6 ядер

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

Примечание 3. Для организации выделенного сервера под 1С на 100 и более пользователей, рекомендуем разворачивать кластер из как минимум двух физических серверов под 1С.

Параметр 2. Объем оперативной памяти

Ее объем тоже представим в виде формулы:

∑озу = 2Гб (для операционной системы) + 2Гб (для SQL сервера) + 2Гб (для сервера приложений) + 2Гб (для обеспечения одновременной работы 10 пользователей) = 8Гб

Причем, это необходимый минимум. Например, для оптимальной работы кэша MS SQL Server рекомендуется выделять 30% от объема баз 1С, для сервера приложений 1С можно расщедриться до 4Гб. Ниже приводим ориентировочный подсчет ОЗУ для сервера 1С:

Источник

Параметры сервера в базе данных Azure для MySQL

Область применения: База данных Azure для MySQL — отдельный сервер

В этой статье приведены советы и рекомендации по настройке параметров сервера в базе данных Azure для MySQL.

Понятие параметров сервера

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

База данных Azure для MySQL предоставляет возможность изменять значение различных параметров сервера MySQL с помощью портала Azure, Azure CLI и PowerShell в соответствии с потребностями рабочей нагрузки.

Настраиваемые параметры сервера

Список поддерживаемых параметров постоянно растет. Для просмотра полного списка и настройки значений параметров сервера используйте вкладку «Параметры сервера» на портале Azure.

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

Пулы потоков

Как правило, MySQL назначает поток для каждого подключения клиента. По мере роста числа одновременно работающих пользователей происходит соответствующее снижение производительности. Многие активные потоки могут значительно влиять на производительность за счет увеличения переключений контекста, состязаний потоков и неправильного местоположения кэшей ЦП.

Пулы потоков, являющиеся серверным компонентом и отличающиеся от пулов подключений, позволяют максимально повысить производительность, путем внедрения динамического пула рабочих потоков, который можно использовать для ограничения количества активных потоков, выполняемых на сервере, и уменьшения их оттока. Благодаря этому увеличение подключений не будет вызывать нехватку ресурсов на сервере или завершаться сбоем из-за ошибки, связанной с недостаточным объемом памяти. Пулы потоков наиболее эффективны для коротких запросов и интенсивных рабочих нагрузок на ЦП (например, рабочих нагрузок OLTP).

Дополнительные сведения о пулах потоков см. в статье Знакомство с пулами потоков в базе данных Azure для MySQL

Компонент пула потоков не поддерживается для версии MySQL 5.6.

Настройка пула потоков

Чтобы включить пул потоков, обновите параметр сервера thread_handling до «pool-of-threads». По умолчанию для этого параметра задано значение one-thread-per-connection , означающее, что MySQL создает новый поток для каждого нового соединения. Обратите внимание, что это статический параметр, для применения которого требуется перезагрузка сервера.

Кроме того, можно настроить максимальное и минимальное количество потоков в пуле, установив следующие параметры сервера:

• thread_pool_max_threads : максимально допустимое число потоков в пуле.
• thread_pool_min_threads : количество потоков, которые будут зарезервированы даже после закрытия подключений.

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

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

Проверьте пул потоков перед его включением в рабочей среде.

log_bin_trust_function_creators

В базе данных Azure для MySQL двоичные файлы журналов всегда включены (т.е. включен параметр log_bin ). При попытке использования триггеров появится сообщение об ошибке типа Отсутствуют права суперпользователя, и включено ведение двоичного журнала (возможно, вы захотите использовать менее надежную переменную log_bin_trust_function_creators ) .

В качестве формата двоичного журнала всегда выбран вариант ROW, а для всех подключений к серверу двоичные журналы ВСЕГДА ведутся на основе строк. При ведении двоичного журнала на основе строк отсутствуют проблемы безопасности и риск сбоев, поэтому для параметра log_bin_trust_function_creators можно безопасно установить значение ИСТИНА.

innodb_buffer_pool_size

Чтобы узнать больше об этом параметре, ознакомьтесь с документацией по MySQL.

Серверы в хранилище общего назначения версии 1 (поддерживается объем данных до 4 ТБ)

Ценовая категория	Виртуальные ядра	Значение по умолчанию (байт)	Минимальное значение (байт)	Максимальное значение (байт)
Basic	1	872415232	134217728	872415232
Basic	2	2684354560	134217728	2684354560
Общее назначение	2	3758096384	134217728	3758096384
Общее назначение	4	8053063680	134217728	8053063680
Общее назначение	8	16106127360	134217728	16106127360
Общее назначение	16	32749125632	134217728	32749125632
Общее назначение	32	66035122176	134217728	66035122176
Общее назначение	64	132070244352	134217728	132070244352
С оптимизацией для операций в памяти	2	7516192768	134217728	7516192768
С оптимизацией для операций в памяти	4	16106127360	134217728	16106127360
С оптимизацией для операций в памяти	8	32212254720	134217728	32212254720
С оптимизацией для операций в памяти	16	65498251264	134217728	65498251264
С оптимизацией для операций в памяти	32	132070244352	134217728	132070244352

Серверы в хранилище общего назначения версии 2 (с поддержкой до 16 ТБ)

Ценовая категория	Виртуальные ядра	Значение по умолчанию (байт)	Минимальное значение (байт)	Максимальное значение (байт)
Basic	1	872415232	134217728	872415232
Basic	2	2684354560	134217728	2684354560
Общее назначение	2	7516192768	134217728	7516192768
Общее назначение	4	16106127360	134217728	16106127360
Общее назначение	8	32212254720	134217728	32212254720
Общее назначение	16	65498251264	134217728	65498251264
Общее назначение	32	132070244352	134217728	132070244352
Общее назначение	64	264140488704	134217728	264140488704
С оптимизацией для операций в памяти	2	15032385536	134217728	15032385536
С оптимизацией для операций в памяти	4	32212254720	134217728	32212254720
С оптимизацией для операций в памяти	8	64424509440	134217728	64424509440
С оптимизацией для операций в памяти	16	130996502528	134217728	130996502528
С оптимизацией для операций в памяти	32	264140488704	134217728	264140488704

innodb_file_per_table

Обновление innodb_file_per_table возможно только в ценовых категориях «Общего назначения» и «Оптимизированная для операций в памяти» в хранилище общего назначения версии 2.

MySQL хранит таблицу InnoDB в разных табличных пространствах в зависимости от конфигурации, указанной при создании таблицы. Табличное пространство системы — это область хранения для словаря данных InnoDB. Табличное пространство file-per-table содержит данные и индексы для одной таблицы InnoDB и хранится в файловой системе в собственном файле данных. Это поведение контролируется серверным параметром innodb_file_per_table . Если задать для innodb_file_per_table значение OFF , InnoDB создаст таблицы в системном табличном пространстве. В противном случае InnoDB создает таблицы в табличных пространствах file-per-table.

База данных Azure для MySQL поддерживает максимальный размер 4 ТБ для одного файла данных в хранилище общего назначения версии 2. Если размер базы данных превышает 4 ТБ, следует создать таблицу в табличном пространстве innodb_file_per_table. Если размер одной таблицы превышает 4 ТБ, следует использовать таблицу секционирования.

join_buffer_size

Чтобы узнать больше об этом параметре, ознакомьтесь с документацией по MySQL.

Ценовая категория	Виртуальные ядра	Значение по умолчанию (байт)	Минимальное значение (байт)	Максимальное значение (байт)
Basic	1	Не настраивается на уровне «Базовый»	Недоступно	Недоступно
Basic	2	Не настраивается на уровне «Базовый»	Недоступно	Недоступно
Общее назначение	2	262144	128	268435455
Общее назначение	4	262144	128	536 870 912
Общее назначение	8	262144	128	1073741824
Общее назначение	16	262144	128	2147483648
Общее назначение	32	262144	128	4294967295
Общее назначение	64	262144	128	4294967295
С оптимизацией для операций в памяти	2	262144	128	536 870 912
С оптимизацией для операций в памяти	4	262144	128	1073741824
С оптимизацией для операций в памяти	8	262144	128	2147483648
С оптимизацией для операций в памяти	16	262144	128	4294967295
С оптимизацией для операций в памяти	32	262144	128	4294967295

max_connections

Ценовая категория	Виртуальные ядра	Значение по умолчанию	Минимальное значение	Максимальное значение
Basic	1	50	10	50
Basic	2	100	10	100
Общее назначение	2	300	10	600
Общее назначение	4	625	10	1250
Общее назначение	8	1250	10	2500
Общее назначение	16	2500	10	5000
Общее назначение	32	5000	10	10000
Общее назначение	64	10000	10	20 000
С оптимизацией для операций в памяти	2	625	10	1250
С оптимизацией для операций в памяти	4	1250	10	2500
С оптимизацией для операций в памяти	8	2500	10	5000
С оптимизацией для операций в памяти	16	5000	10	10000
С оптимизацией для операций в памяти	32	10000	10	20 000

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

ОШИБКА 1040 (08004): Слишком много подключений

Для обеспечения оптимальной работы рекомендуется использовать пул подключений, например ProxySQL, чтобы эффективно управлять подключениями.

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

ProxySQL — это продукт сообщества разработчиков решений с открытым кодом. Это решение по мере возможности поддерживается корпорацией Майкрософт. Чтобы получить помощь и полезные инструкции для своей рабочей среды, вы можете обратиться в службу поддержки продуктов ProxySQL.

max_heap_table_size

Чтобы узнать больше об этом параметре, ознакомьтесь с документацией по MySQL.

Ценовая категория	Виртуальные ядра	Значение по умолчанию (байт)	Минимальное значение (байт)	Максимальное значение (байт)
Basic	1	Не настраивается на уровне «Базовый»	Недоступно	Недоступно
Basic	2	Не настраивается на уровне «Базовый»	Недоступно	Недоступно
Общее назначение	2	16777216	16384	268435455
Общее назначение	4	16777216	16384	536 870 912
Общее назначение	8	16777216	16384	1073741824
Общее назначение	16	16777216	16384	2147483648
Общее назначение	32	16777216	16384	4294967295
Общее назначение	64	16777216	16384	4294967295
С оптимизацией для операций в памяти	2	16777216	16384	536 870 912
С оптимизацией для операций в памяти	4	16777216	16384	1073741824
С оптимизацией для операций в памяти	8	16777216	16384	2147483648
С оптимизацией для операций в памяти	16	16777216	16384	4294967295
С оптимизацией для операций в памяти	32	16777216	16384	4294967295

query_cache_size

По умолчанию кэш запросов отключен. Чтобы включить кэш запросов, настройте параметр query_cache_type .

Чтобы узнать больше об этом параметре, ознакомьтесь с документацией по MySQL.

Кэш запросов устарел в MySQL 5.7.20 и был удален в MySQL 8.0

Ценовая категория	Виртуальные ядра	Значение по умолчанию (байт)	Минимальное значение (байт)	Максимальное значение
Basic	1	Не настраивается на уровне «Базовый»	Недоступно	Недоступно
Basic	2	Не настраивается на уровне «Базовый»	Недоступно	Недоступно
Общее назначение	2	0	0	16777216
Общее назначение	4	0	0	33554432
Общее назначение	8	0	0	67108864
Общее назначение	16	0	0	134217728
Общее назначение	32	0	0	134217728
Общее назначение	64	0	0	134217728
С оптимизацией для операций в памяти	2	0	0	33554432
С оптимизацией для операций в памяти	4	0	0	67108864
С оптимизацией для операций в памяти	8	0	0	134217728
С оптимизацией для операций в памяти	16	0	0	134217728
С оптимизацией для операций в памяти	32	0	0	134217728

lower_case_table_names

По умолчанию параметру lower_case_table_name присвоено значение 1. Его можно обновить в MySQL 5.6 и MySQL 5.7

Чтобы узнать больше об этом параметре, ознакомьтесь с документацией по MySQL.

В MySQL 8.0 параметру lower_case_table_name по умолчанию присвоено значение 1, и менять его нельзя.

innodb_strict_mode

Если появляется сообщение об ошибке, похожее на «Слишком большой размер строки (> 8126)», может потребоваться отключить параметр innodb_strict_mode. Параметр сервера innodb_strict_mode не может быть изменен глобально на уровне сервера, так как если размер данных строки превысит 8 КБ, данные будут обрезаны без ошибок, приводящих к возможной потере данных. Рекомендуется изменить схему в соответствии с предельным размером страницы.

Этот параметр можно задать на уровне сеанса с помощью init_connect . Сведения о том, как задать innodb_strict_mode на уровне сеанса, см. в разделе об отсутствии в списке параметра настройки.

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

sort_buffer_size

Чтобы узнать больше об этом параметре, ознакомьтесь с документацией по MySQL.

Ценовая категория	Виртуальные ядра	Значение по умолчанию (байт)	Минимальное значение (байт)	Максимальное значение (байт)
Basic	1	Не настраивается на уровне «Базовый»	Недоступно	Недоступно
Basic	2	Не настраивается на уровне «Базовый»	Недоступно	Недоступно
Общее назначение	2	524288	32768	4194304
Общее назначение	4	524288	32768	8388608
Общее назначение	8	524288	32768	16777216
Общее назначение	16	524288	32768	33554432
Общее назначение	32	524288	32768	33554432
Общее назначение	64	524288	32768	33554432
С оптимизацией для операций в памяти	2	524288	32768	8388608
С оптимизацией для операций в памяти	4	524288	32768	16777216
С оптимизацией для операций в памяти	8	524288	32768	33554432
С оптимизацией для операций в памяти	16	524288	32768	33554432
С оптимизацией для операций в памяти	32	524288	32768	33554432

tmp_table_size

Чтобы узнать больше об этом параметре, ознакомьтесь с документацией по MySQL.

Ценовая категория	Виртуальные ядра	Значение по умолчанию (байт)	Минимальное значение (байт)	Максимальное значение (байт)
Basic	1	Не настраивается на уровне «Базовый»	Недоступно	Недоступно
Basic	2	Не настраивается на уровне «Базовый»	Недоступно	Недоступно
Общее назначение	2	16777216	1024	67108864
Общее назначение	4	16777216	1024	134217728
Общее назначение	8	16777216	1024	268435456
Общее назначение	16	16777216	1024	536 870 912
Общее назначение	32	16777216	1024	1073741824
Общее назначение	64	16777216	1024	1073741824
С оптимизацией для операций в памяти	2	16777216	1024	134217728
С оптимизацией для операций в памяти	4	16777216	1024	268435456
С оптимизацией для операций в памяти	8	16777216	1024	536 870 912
С оптимизацией для операций в памяти	16	16777216	1024	1073741824
С оптимизацией для операций в памяти	32	16777216	1024	1073741824

Прогрев буферного пула InnoDB

После перезапуска сервера базы данных Azure для MySQL страницы данных, размещенные на диске, загружаются по мере запроса таблиц. Это приводит к увеличению задержки и снижению производительности при первом выполнении запросов. Такая ситуация может быть неприемлемой для рабочих нагрузок, чувствительных к задержкам. Использование буферного пула InnoDB позволяет сократить период «прогрева», перезагружая дисковые страницы, которые были в буферном пуле до перезапуска, не ожидая операций DML или SELECT для доступа к соответствующим строкам.

Вы можете уменьшить период «прогрева» после перезапуска сервера Базы данных Azure для MySQL, повысив производительность путем настройки параметров сервера буферного пула InnoDB. InnoDB сохраняет долю последних использованных страниц для каждого буферного пула при завершении работы сервера и восстанавливает эти страницы при запуске сервера.

Важно также отметить, что повышение производительности достигается за счет более длительного времени запуска сервера. Если этот параметр включен, время запуска и перезапуска сервера в зависимости от количества операций ввода-вывода, подготовленных на сервере, должно возрасти. Рекомендуется тестировать и отслеживать время перезапуска, чтобы обеспечить приемлемую производительность при запуске и перезапуске, так как сервер в это время недоступен. Не рекомендуется использовать этот параметр, если подготовлено менее 1000 операций ввода-вывода в секунду (или когда объем подготовленного хранилища меньше 335 ГБ).

Чтобы сохранить состояние буферного пула при завершении работы сервера, присвойте параметру сервера innodb_buffer_pool_dump_at_shutdown значение ON . Аналогичным образом задайте для параметра сервера innodb_buffer_pool_load_at_startup значение ON , чтобы восстановить состояние буферного пула при запуске сервера. Управлять влиянием на время запуска или перезапуска можно путем уменьшения и точной настройки значения параметра сервера innodb_buffer_pool_dump_pct . По умолчанию значение этого параметра равно 25 .

Параметры «прогрева» буферного пула InnoDB поддерживаются только на серверах хранилищ общего назначения с хранилищем объемом до 16 ТБ. Дополнительные сведения о возможностях хранилищ Базы данных Azure для MySQL см. здесь.

time_zone

После первоначального развертывания Azure для сервера MySQL включает системные таблицы для сведений о часовом поясе, но эти таблицы не заполнены. Таблицы часовых поясов можно заполнить, вызвав хранимую процедуру mysql.az_load_timezone с помощью такого инструмента, как командная строка MySQL или MySQL Workbench. Инструкции по вызову хранимой процедуры и настройке часовых поясов глобального времени или уровня сеанса см. в статьях Портал Azure и Интерфейс командной строки Azure.

binlog_expire_logs_seconds

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

Двоичный журнал содержит «события», которые описывают изменения в базе данных, такие как операции создания таблицы или изменения данных таблицы. Он также содержит события для инструкций, которые могли бы внести изменения. Двоичный журнал используется в основном для репликации и операции восстановления данных. Как правило, двоичные журналы очищаются, как только этот дескриптор освобождается от службы, резервной копии или набора реплик. В случае с несколькими репликами они ждут, пока самая медленная реплика прочитает изменения, прежде чем она будет очищена. Если вы хотите сохранить двоичные журналы в течение более длительного времени, можно настроить параметр binlog_expire_logs_seconds. Если binlog_expire_logs_seconds имеет значение 0 (значение по умолчанию), он будет очищен сразу после освобождения дескриптора двоичного журнала. Если binlog_expire_logs_seconds больше 0, то он будет ждать до истечения настроенных секунд перед очисткой. Для Базы данных Azure для MySQL управляемые функции, такие как резервное копирование и очистка двоичных файлов от копий для чтения, обрабатываются внутренним образом. При репликации данных из службы Базы данных Azure для MySQL этот параметр должен быть установлен в первичном виде, чтобы избежать очистки двоичных журналов до того, как реплика прочитает изменения из первичной. Если для параметра binlog_expire_logs_seconds задано более высокое значение, двоичные журналы не будут очищаться достаточно быстро, что может привести к увеличению счета за хранилище.

Ненастраиваемые параметры сервера

Перечисленные ниже параметры сервера нельзя настроить в службе.

Параметр	Фиксированное значение
innodb_file_per_table для уровня «Базовый»	OFF
innodb_flush_log_at_trx_commit	1
sync_binlog	1
innodb_log_file_size	256 МБ
innodb_log_files_in_group	2

Другим переменным, не указанным здесь, присваиваются значения по умолчанию MySQL. Значения по умолчанию см. в документации по MySQL для версий 8.0, 5.7 и 5.6.

Источник