Опыт миграции из собственного датацентра в облако AWS

Публикация № 860772

Администрирование - Производительность и оптимизация (HighLoad)

AWS базы данных миграция

20
Хотя данная публикация и не имеет прямого отношения к 1С, она может быть интересна тем, кто занимается крупными базами данных на MS SQL Server. Описывается опыт миграции баз данных в облако AWS в компании glassdoor.com, где я занимался этим проектом. Это первый драфт текста, получившийся довольно скомканным - в процессе буду дополнять.

Компания glassdoor.com является вторым по трафику сайтом в США для соискателей работы. SLA установлен на уровне 99.99% без возможности проводить обслуживание серверов и приложений в оффлайн режиме. Объем баз данных, которые должны быть мигрированы в облако - порядка 40Тб. В среднем сервера баз данных выполняют 2 млрд. запросов в день.

 

Ситуация до миграции

Для обеспечения высокой доступности (HADR) используется стандартная технология SQL Server Failover Cluster Instance.

 

 

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

  1. Для работы кластера требуется дорогостоящее сетевое хранилище данных (SAN), подключенное оптическими каналами ко всем нодам кластера.

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

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

  4. Клиентские приложения написаны на java и работают под управлением Linux. Используется устаревшая версия jdbc-драйвера, которая официально поддерживает только SQL2008, хотя сами базы данных были переведены на SQL2016.

  5. Лицензии на SQL2016 уже были оплачены.

 

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

  1. AWS не поддерживает общее хранилище данных для Windows. Использование  SQL Server Failover Cluster Instance невозможно.

  2. AWS не поддерживает свободный переход IP-адресов между серверами. Windows не сможет сама переместить клиентский адрес доступа на новую ноду при переключении между нодами.

  3. Требуется повысить уровень отказоустойчивости при авариях.

  4. Убедится, что все клиентские приложения на должном уровне поддерживают подключение к кластеру баз данных в новой архитектуре.

  5. Использовать свои лицензии на SQL Server.

Лицензирование

Политика Microsoft в части лицензирования баз данных в облаке довольно сложная.

Я бы выделил три возможных варианта для AWS:

  1. Для компаний с большим бюджетом дополнительные соглашения с Microsoft позволяют запускать виртуальные машины с SQL Server в облаке без особых ограничений. Вы можете запустить новую Windows VM, установить SQL и использовать без каких дополнительных манипуляций.

  2. AWS предоставляет возможность запустить Windows VM с предустановленным SQL Server. При этом оплата производиться по фактическому использованию. К примеру один сервер с 512 Gb RAM и 64 CPU обойдется примерно в $23000/месяц.

  3. Использовать собственные лицензии SQL Server в облаке AWS.

 

Для нас был приемлем только третий вариант:

  • SQL Server должен запускаться на выделенном физическом сервере. Звучит глупо.. облако.. физический сервер, но AWS поддерживает такую возможность.

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

  • AWS не позволит использовать публичные образы Windows для запуска VM на выделенном сервере. Потребуется создать собственный образ Windows VM собственными силами с помощью Hyper-V или VMWare, а затем экспортировать этот образ в AWS. Образ должен содержать собственную лицензию Windows и активироваться собственными KMS.

  • AWS не поддерживает автоматическое восстановление при аварии для таких виртуальных машин. Если физический сервер умирает вы должны перевести виртуальные машины на новый сервер самостоятельно.

При построении образа потребуется установить соответствующие драйверы для работы в AWS - драйвер хранилища и сетевой драйвер.

 

Выбор HADR архитектуры

Учитывая ограничения AWS на общее сетевое хранилище, было решено использовать SQL Server AlwaysOn.

Основные достоинства:

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

  2. Процесс фейловера занимает всего несколько секунд. В отличие от SQL FCI, нет необходимости завершать основной процесс базы данных и запускать его на новом сервере. Фейловер в SQL FCI обычно требовал 5 минут из-за агрессивности клиентских приложений.

  3. Возможность перенести нагрузку резервного копирования на другие ноды.

Недостатки:

  1. Двойной коммит - все синхронные ноды должны зафиксировать коммит одновременно с мастер нодой. В результате, производительность UPDATE\DELETE\INSERT операций в AlwaysOn ниже, чем в SQL FCI.

  2. Восстановление AlwaysOn ноды с нуля требует значительно большего времени, чем восстановление ноды в SQL FCI, т.е. необходимо восстановить все базы данных.

 

Невозможность перемещения IP адреса между нодами средствами Windows также накладывает ограничения на целевую архитектуру:

  1. Каждая нода, вовлеченная в процесс фейловера, должна находится в отдельной подсети. В этом случае Windows Failover Cluster позволит установить выделенный IP-адрес для каждой ноды и его перемещение в процессе фейловера не потребуется.

  2. Каждая нода должна иметь только один сетевой интерфейс для каждой подсети. Если требуется два интерфейса - расположите их в разных подсетях. Это позволит избежать проблемы, когда Windows Failover Cluster пытается активировать клиентский IP адрес на ошибочном сетевом интерфейсе.

 

Принимая во внимание рекомендации по расположению серверов баз данных в разных зонах получаем следующую архитектуру:

Две синхронные реплики в регионе us-east-1. Одна асинхронная реплика в us-west-2. Синхронные реплики позволяют защититься от аварий на уровне одного датацентра (на самом деле не так уж и редки). Асинхронная реплика страхует на случай аварии на уровне региона - но это уже на случай серьезного катаклизма, при котором автоматическое восстановление работы сайта невозможно - потребуется ручной перевод трафика в другой регион.

 

Выбор типа виртуальной машины

При всем многообразии типов VM в AWS, только три могут использоваться для баз данных эффективно.

  1. I3 - наибольший инстанс имеет 512 Gb RAM и 64 CPU. Дополнительно имеется 16Tb локальных быстродействующих SSD, которые могут быть использованы для tempdb и buffer pool extension.
    После ряда болезненных экспериментов мы пришли к выводу, что этот тип для нас не подходит. Вроде как там используется устаревший гипервизор, который тратит слишком много ресурсов на поддержку VM. Например, под большой нагрузкой утилизация CPU на физическом сервер была в 2 раза больше, чем внутри виртуальной машины.

  2. X1E - один из самых новых типов. Наибольший инстанс имеет 4096 Gb RAM и 128 CPU. Работает просто отлично, но цена…

  3. R4 - наибольший инстанс имеет 512 Gb RAM и 64 CPU. Приемлемая цена и хорошая производительность. Используется новая версия гипервизора с малыми издержками на виртуализацию.

 

При выборе размера инстанса необходимо учитывать ограничения на скорость доступа к сети и скорость доступа к хранилищу. Чем больше инстанс - тем выше лимиты.

Тип инстанса

Максимальная пропускная способность хранилища (MB/s, 128 KB I/O)

Максимум IOPS (16 KB I/O)

i3.8xlarge

875

32,500

i3.16xlarge

1,750

65,000

r4.8xlarge

875

37,500

r4.16xlarge

1,750

75,000

x1e.16xlarge

875

40,000

x1e.32xlarge

1,750

80,000

 

Конфигурация хранилища

AWS Elastic Block Storage позволяет выбрать из нескольких видов хранилища, каждый из который имеет свои лимиты и особенности.

 

Solid-State Drives (SSD)

Hard disk Drives (HDD)

Volume Type

General Purpose SSD (gp2)*

Provisioned IOPS SSD (io1)

Throughput Optimized HDD (st1)

Cold HDD (sc1)

Max. IOPS**/Volume

10,000

(when volumes size is > 3333Gb)

32,000

500

250

Max. Throughput/Volume

160 MiB/s

500 MiB/s***

500 MiB/s

(40 MB/s per TiB)

250 MiB/s

Use case

Database files

Database files

Database backups

<not being used>

 

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

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

В-третьих, чтобы получить максимальную производительность необходимо использовать RAID0 из правильно подобранного числа томов.

RAID0 не обеспечивает защиты данных за счет дупликации, но обеспечивает максимальную производительность за счет записи данных в разные тома.

К примеру наша конфигурация для r4.16xlarge сервера:

  1. Операционная система - C:\ - 300Gb. Тип тома - gp2. Стоимость в месяц $27.

  2. Базы данных с логами, tempdb - X:\ - 34Tb - десять томов gp2, каждый 3400Gb, объединенных в RAID0 средствами Windows Storage Spaces. Стоимость в месяц $3400.
    Как вышли на эту конфигурацию:

    1. Инстанс этого типа имеет лимит в 1750MB/s и 75000 IOPS.

    2. Один том gp2 имеет лимит в 160MB/s и до 10000 IOPS.

    3. Чтобы избежать проседания производительности размер каждого тома должен быть не менее 3333 Gb.

    4. Десять томов gp2, объединенных в RAID0 позволяют максимально утилизировать доступный лимит для инстанса и обеспечить максимальную пропускную способность.

Такого же эффекта можно добиться с помощью четырех io1 томов 20000 IOPS в каждом. Размер при этом не имеет значения. Но такая конфигурация обойдется значительно дороже при меньшей емкости. Например, 4 тома по 3000 Gb обойдутся в $6700 в месяц.

  1. Бэкапы - S:\ - 4Tb - один том st1. Стоимость в месяц $180 (в два раза дешевле gp2, при хорошей производительности для бэкапов).

 

Бэкапы баз данных

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

  1. Бэкап базы данных выполняется на главной ноде на “локальный” диск S:\. Диск является EBS томом, поэтому беспокоится за его сохранность не стоит - том можно переключить на другой сервер даже если виртуальная машина полностью потеряна. Локальный том хранит бэкапы за последние 7 дней.

  2. По субботам полный бэкап загружается в AWS S3 на долговременное хранение. Для файлов изначально устанавливается тип хранилища “нечастый доступ”, а по истечение 45 дней файлы автоматически выгружаются в AWS Glacier. В итоге долговременное хранилище большого объема файлов выходит относительно дешево.

 

Клиентские приложения

В процессе работы над проектом мы осознали, что используемый jdbc-драйвер не сможет эффективно работать в новой конфигурации, т.к. он не поддерживает клиентские точки доступа с несколькими IP-адресами (multi-subnet cluster). Кстати, платформа 1С также не поддерживает такую конфигурацию в чистом виде - мне не удалось заставить сервер 1С стабильно подключаться к AlwaysOn кластеру с несколькими IP-адресами. Хотя, с определенными оговорками, есть вариант как это решить.

Суть проблемы в том, что для используемого доменного имени DNS сервер возвращает два (или больше) IP адреса вместо одного. Но только один адрес, принадлежащий мастер ноде, является активным.

Для решения проблемы нужно всего лишь добавить параметр “MultiSubnetFailover=True” в строку соединения. Но не всегда есть возможность сделать это.

Варианты решения, если поменять строку соединения невозможно:

  1. Windows Failover Cluster имеет параметр, который позволяет обновлять IP адрес в DNS и регистрировать только один адрес, который активен в данный момент. Минусы:

    1. в процесс фейловера вовлечен дополнительный участник (DNS сервер).

    2. DNS кэш на клиентских серверах обновляется не так часто.

    3. Дополнительные сложности возникнут если клиенты на Linux.

В результате сложно ожидать восстановления нормальный работы приложений быстрее чем через 5-10 минут после фейловера.

  1. Использовать один из сервисов AWS - Network Load Balancer

    1. NLB корректно определяет активную ноду и меняет DNS запись.

    2. Нормально работает в Linux.

    3. Проблема с DNS кэшем все равно присутствует.

Время на восстановление также 5-10 минут.

  1. Использовать решения типа HAProxy

    1. С точки зрения клиента IP адрес не меняется.

    2. Время восстановления после фейловера может приблизится к 30-60 секундам.

    3. Для построения реальной отказоустойчивости на уровне HAProxy требуется построение довольно сложной архитектуры. Один из вариантов: два HAProxy + AWS Network Load Balancer. В этом случае сбой на одном HAProxy не приведет к полной потере доступа к базе данных.

 

Непосредственная миграция

Одним из условий проекта была возможность быстрого возврата в локальный датацентр при проблемах в AWS, поэтому было решено использовать AlwaysOn как средство миграции баз данных. Хотя технически это можно назвать обычным процессом фейловера между нодами, расположенными в разных датацентрах.

 

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

Затем веб-сайт переводится в оффлайн режим, производится фейловер базы данных в AWS и AlwaysOn переключается обратно в асинхронный режим. В этом время, трафик переключается на приложения в AWS, которые уже подключены в новой мастер ноде.
Суммарное время даунтайма - 6 минут!

20

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. grumagargler 612 30.07.18 00:09 Сейчас в теме
Подскажите пожалуйста, в статье описаны особенности и сложности перехода, но непонятно зачем вы это делали?
2. Aleksey.Bochkov 3237 30.07.18 02:55 Сейчас в теме
(1) Задача была перевести все приложения в облако, для того, чтобы ускорить развитие бизнеса в конечном счете. В своем датацентре требуется минимум пара недель для получения нового сервера, в облаке же это вопрос пары минут.
JohnyDeath; +1 Ответить
3. mad375 30.07.18 05:15 Сейчас в теме
Было очень интересно, спасибо
4. ihtiking 01.08.18 12:45 Сейчас в теме
Дороговато выходит.... После перехода Вы почувствовали изменения к лучшему с точки зрения бизнеса или с точки зрения ИТ ?
5. Aleksey.Bochkov 3237 03.09.18 23:05 Сейчас в теме
(4) По словам CTO, в долговременной перспективе расходы на инфраструктуру после перехода в AWS ожидаются на 10-20% меньше расходов на собственный датацентр.
Изменения к лучшему заметили практически на всех уровнях:
- цикл разработки новой функциональности ускорился
- стало легче реагировать на скачки трафика (сервера приложений масштабируются горизонтально в течение пары минут)
- проще устранять проблемы
- и, как бы странно это ни звучало, сайт работает существенно быстрее в AWS.
6. kiruha 380 15.10.18 11:05 Сейчас в теме
glassdoor.com из США обратился во франч 1С в России для перевода дата центра ?
7. Aleksey.Bochkov 3237 15.10.18 20:14 Сейчас в теме
(6) я работаю в этой компании. Живу в Сан Франциско.
AQR84; Krio2; kiruha; +3 Ответить
Оставьте свое сообщение

См. также

Набор скриптов для знакомства с SQL Server 201

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad) Администрирование СУБД

Поговорим о скриптах, которые помогут быстро ознакомиться с состоянием SQL Server, в том числе с вопросами производительности.

30.09.2019    8668    YPermitin    10       

Мониторинг высоконагруженной системы 37

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad) Администрирование данных 1С

Высоконагруженной системе (более 8000 клиентских сессий) мониторинг необходим. Про опыт использования инструментов для мониторинга – самописной системы информирования, написанной на C#, и конфигурации «Центр контроля качества» в связке с системой отображения данных Grafana, на конференции Infostart Event 2018 Education рассказал Олег Репников.

13.09.2019    3355    Repich    4       

Использование Zabbix для сбора информации о серверных вызовах и управляемых блокировках с сервера 1С Предприятия, работающего на платформе GNU/Linux 72

Статья Системный администратор Программист Нет файла v8 Linux Бесплатно (free) Администрирование данных 1С Zabbix

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    6823    Sloth    11       

Руководство по SQL: Как лучше писать запросы (Часть 2) 33

Статья Системный администратор Программист Нет файла СУБД Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию продолжение перевода статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Первая часть доступна по ссылке https://infostart.ru/public/1115809/

03.09.2019    3303    w.r.    1       

Анализ производительности APDEX 65

Отчеты и формы Системный администратор Программист Внешний отчет (ert,erf) v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.

31.08.2019    2576    93    YPermitin    7       

Руководство по SQL: Как лучше писать запросы (Часть 1) 59

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Узнайте о антипаттернах, планах выполнения, time complexity, настройке запросов и оптимизации в SQL.

30.08.2019    4559    w.r.    0       

Использование Union вместо OR 5

Статья Системный администратор Программист Нет файла MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Derek Dieter "Using Union Instead of OR". Оригинал доступен по ссылке http://sqlserverplanet.com/optimization/using-union-instead-of-or.

22.08.2019    1426    w.r.    35       

Тюнинг производительности запросов в PostgreSQL 33

Статья Системный администратор Программист Нет файла PostgreSQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Brady Holt "Performance Tuning Queries in PostgreSQL ". Оригинал доступен по ссылке https://www.geekytidbits.com/performance-tuning-postgres/

31.07.2019    3080    w.r.    5       

Неочевидные проблемы производительности: важность системного подхода при анализе 50

Статья Программист Нет файла v8 Россия MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Часто программисты и 1С-ники сталкиваются с совершенно необъяснимыми на первый взгляд проблемами. Но это потому, что их внимание направлено только на один сегмент системы, а не на всю систему полностью. О том, почему нужно стараться смотреть на ситуацию комплексно, рассказал специалист по производительности компании SOFTPOINT Александр Денисов.

19.07.2019    4094    Филин    12       

Ловля блокировок на связке "Microsoft SQL server - 1С" 38

Статья Системный администратор Программист Нет файла v8 v8::blocking MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Материал относится к базам данных на связке «1С - MS SQL Server». Один из способов отлова блокировок в бд 1С . Переход к управляемым блокировкам через режим "Автоматический и управляемый".

16.07.2019    3456    fhqhelp    0       

Настройка параметров PostgreSQL для оптимизации производительности 33

Статья Системный администратор Программист Нет файла PostgreSQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Ibrar Ahmed "Tuning PostgreSQL Database Parameters to Optimize Performance". Оригинал доступен по ссылке https://www.percona.com/blog/2018/08/31/tuning-postgresql-database-parameters-to-optimize-performance/

08.07.2019    3129    w.r.    13       

Сравнительное тестирование работы PostgreSQL с большими страницами Linux 6

Статья Системный администратор Программист Нет файла Linux Бесплатно (free) Производительность и оптимизация (HighLoad)

Представляю вашему вниманию перевод статьи Ibrar Ahmed "Benchmark PostgreSQL With Linux HugePages". Оригинал расположен по ссылке https://www.percona.com/blog/2018/12/20/benchmark-postgresql-with-linux-hugepages/

05.07.2019    1615    w.r.    6       

Настройка параметров ядра Linux для оптимизации PostgreSQL 33

Статья Системный администратор Программист Нет файла Linux Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Ibrar Ahmed "Tune Linux Kernel Parameters For PostgreSQL Optimization". Оригинал доступен по ссылке https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/

05.07.2019    2233    w.r.    1       

Анти-оптимизация: как мы ускорили запрос в 4 раза, сделав его неоптимальным 57

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Решение задач на 1С:Специалист Разработка

В этой статье приведен пример неочевидной "оптимизации" запроса, которая противоречит всем правилам, описанным в книгах для подготовки к сертификации "1С:Эксперт по технологическим вопросам", а также преподаваемым на курсах подготовки экспертов.

02.07.2019    5925    igordynets    119       

Сравнительное тестирование PostgreSQL на FreeBSD, CentOS, Ubuntu Debian и openSUSE 7

Статья Системный администратор Программист Нет файла PostgreSQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Данная статья является переводом оригинальной статьи Martin Kov&#225;&#269;ik "PostgreSQL benchmark on FreeBSD, CentOS, Ubuntu Debian and openSUSE" https://redbyte.eu/en/blog/postgresql-benchmark-freebsd-centos-ubuntu-debian-opensuse/ В ней рассматриваются тесты СУБД PostgreSQL 10.1 в приближенных к реальным условиям средах на различных unix-системах

30.06.2019    3352    w.r.    2       

Ускорение чтения правил обмена в УПП 1.3 в 20 раз! 66

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Способ оптимизации чтения правил обмена конвертации данных. Может понадобиться при большом размере правил и высокой периодичности обмена.

27.06.2019    4069    YPermitin    16       

Хотите снизить нагрузку на процессор сервера в 2 раза? 21

Статья Системный администратор Программист Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

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

27.06.2019    4039    Дмитрий74Чел    6       

Непридуманные истории по оптимизации. История 1 78

Статья Системный администратор Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Первая статья из планируемого цикла об оптимизации приложений на базе 1С. Без теории. Одна практика.

13.06.2019    7027    Repich    117       

Оптимизация: неэффективные запросы 6

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Разработка

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

13.06.2019    2583    slayer-ekb    10       

За 5 шагов добавляем мониторинг счетчиков производительности серверов MS SQL и 1С 90

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Статистика базы данных Производительность и оптимизация (HighLoad)

Мы расскажем и покажем, как добавить данные счетчиков производительности серверов 1С и MS SQL в нашу базу мониторинга за 15 минут. Приведем список наиболее важных из них, опишем основные особенности.

28.05.2019    7025    ivanov660    5       

Не думать о секундах свысока... 55

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Несколько примеров оптимизации типовой конфигурации УТ11. Описанные приемы подходят для многих других конфигураций.

21.05.2019    4309    vasilev2015    21       

Альтернативная стратегия управления блокировками 45

Статья Программист Архив с данными v8 v8::blocking 1cv8.cf Россия MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Данная публикация освещает одну из альтернативных стратегий блокирования данных на уровне MS SQL Server, которая недоступна средствами 1С, но может быть весьма полезной. Разбирается практический пример.

20.05.2019    3701    zhichkin    15       

Как работают управляемые блокировки 120

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

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

29.04.2019    12993    comol    198       

Странное потребление места на диске С 33

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Решение проблемы постоянного роста папки %AppData%/Local/Temp.

26.04.2019    10551    kuzyara    12       

Диспетчер Хранилища Запросов в SQL Server 2016+ (он же Query Store) 36

Статья Системный администратор Нет файла MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

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

26.04.2019    6976    Aleksey.Bochkov    7       

Включение встроенного в платформу механизма "Копии базы данных" и использование "Дата Акселератора". Новый стандартный механизм использования баз OLAP в 1С 49

Статья Системный администратор Программист Нет файла v8 Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

С версии 1С 8.3.14 в платформе появился новый функционал «Копии базы данных». В данной публикации я хочу рассказать, как включить использование данного механизма в платформе 1с и как его использовать для получения отчетов с копии базы данных, которая может быть вынесена на внешний сервер относительно текущей базы данных, а также как использовать систему «Дата акселератор», в которой база данных целиком размещена в оперативной памяти рабочего сервера кластера серверов «1С:Предприятия».

25.04.2019    8107    Elf1k    26       

Мониторим тяжелые запросы 28

Статья Системный администратор Программист Нет файла MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Мониторинг тяжелых запросов с сохранением результатов для истории.

22.04.2019    3880    ImHunter    8       

Копия базы 1С для отчетов. Или как выжить с тяжелой отчетностью 105

Статья Системный администратор Нет файла Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

Способы создания копии базы 1С для отчетов. Бэкапирование, репликация, AlwaysOn и другие страшные слова.

22.04.2019    8008    YPermitin    47       

5 простых шагов и 15 минут на разворачивание инструмента мониторинга проблем производительности базы 1С 201

Статья Системный администратор Программист Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

В этой статье мы разберем механизм использования конфигурации "Анализ технологического журнала" на практике, и всего через 15 минут работы вы получите функциональный, удобный инструмент мониторинга проблем производительности базы 1С.

18.04.2019    17708    ivanov660    40       

Самый быстрый шринк на Диком Западе 67

Статья Системный администратор Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad)

Шринк (shrink) базы данных. Наглядное объяснение что это, зачем, когда применять и как это можно ускорить.

17.04.2019    7067    YPermitin    44       

Как разбить базу на файлы и не сойти с ума 108

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Разбиение базы данных 1C на файлы и последующее сопровождение. Нюансы, грабли и прочее.

06.04.2019    8561    YPermitin    29       

Как одно изменение конфигурации PostgreSQL улучшило производительность медленных запросов в 50 раз 124

Статья Системный администратор Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

В связи с санкциями и другими событиями сейчас все более и более актуальна тема перевода ПО компаний на отечественное и свободное программное обеспечение. Одной из самых востребанных СУБД на рынке на данный момент является PostgreSQL - надежная, высокопроизводительная и хорошо масштабируемая СУБД, которая является прямым конкуретном таким крупным компаниям с их топовыми продуктами, как Oracle, IBM и Microsoft. Однако каждый, кто переходит на PostgreSQL, сталкивается с трудностями, прежде всего с настройкой и производительностью. Не обошли проблемы с производительностью "слоника" и меня. Предлагаю вашему вниманию перевод статьи "How a single PostgreSQL config change improved slow query performance by 50x" автора Pavan Patibandla, которая мне помогла улучшить производительность PostgreSQL.

18.03.2019    9711    w.r.    23       

Быстрее чем INSERT! BULK-операции и примеры использования 112

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Разработка Внешние источники данных Перенос данных из 1C8 в 1C8

Microsoft SQL Server поддерживает так называемые BULK-операции, используемые для быстрого изменения больших объемов данных в базе. В статье пойдет речь о практических примерах их использования. Все примеры сделаны в контексте платформы 1С (а как иначе).

09.03.2019    9650    YPermitin    38       

Простое программное решение проблем с блокировками SQL 17

Статья Системный администратор Программист Нет файла v8 v8::blocking 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Описание одного из способов программного решения проблемы блокировок при проведении документов в клиент-серверной 1С.

06.03.2019    5792    dmitrydemenew    38       

Другой взгляд на APDEX и подсистему "Оценка производительности" 81

Статья Системный администратор Программист Нет файла 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Описание принципа работы подсистемы "Оценка производительности" из БСП, примеров использования, недостатках подсистемы, а также рассуждение о путях улучшения мониторинга производительности в системах 1С.

20.02.2019    8899    YPermitin    30       

Секционирование таблиц и индексов в мире 1С 157

Статья Системный администратор Программист Нет файла MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Говорим о секционировании таблиц и индексов для баз 1С. Способы применения, подводные камни и прочее.

10.02.2019    10918    YPermitin    53       

Производительность сервера 1С и фоновые задания 63

Статья Системный администратор Нет файла v8 1cv8.cf Россия Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

В падении производительности сервера 1С зачастую виноваты не регламентные / фоновые задания, они выполняют полезную работу. Но задания нельзя оставлять «наедине» с базой.

05.02.2019    10643    user715208    38       

Инструкция: ускоряем tempdb переносом в RAM диск 90

Статья Системный администратор Нет файла Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

При работе 1С:Предприятия 8 в режиме клиент-сервер широко используются временные таблицы. Кроме того, TEMPDB используется Microsoft SQL Server при выполнении запросов, использующих операторы GROUP BY, UNION, DISTINCT и т.п. Эта служебная БД весьма нагружена и её ускорение сулит нам серьезный выигрыш в производительности. Давайте же поместим её в RAM.

29.01.2019    12740    MrWonder    79       

Управляемые блокировки по полям из свойства "Поля блокировки данных" 5

Статья Программист Нет файла v8::blocking Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Разработка

Добрый день, коллеги! Хотелось бы поделиться обнаруженной особенностью работы механизма управляемых блокировок, а именно блокировке по полям, указанным в свойстве «Поля блокировки данных».

24.01.2019    3860    mshumakov    1       

Элементарный способ ускорить вашу 1С в два-три раза 71

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad)

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

14.12.2018    27313    Aleksey81    43       

Создаем свои индексы для баз 1С. Со своей структурой и настройками! 124

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad)

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

05.11.2018    11953    YPermitin    31       

Новый режим реструктуризации (обновление базы данных на сервере в режиме v2) 168

Статья Системный администратор Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

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

31.10.2018    18216    Dach    46       

Нетривиальные подходы в решении всем известных проблем: ускорение «больших» документов в 1С и ускорение поиска по подстроке. Как добиться эффекта в разы? 62

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Часто у пользователей 1С поиск информации по большим спискам данных по подстроке занимает продолжительное время. Павел Баркетов рассматривает причины торможения запросов с поиском по подстроке и описывает возможности и подходы к их оптимизации и ускорению. Также в статье разобраны причины длительного проведения «больших» документов (более 10 000 строк) и даны рекомендации по ускорению этих операций.

30.08.2018    10725    gallam99    31