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

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

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

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

Хотя данная публикация и не имеет прямого отношения к 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 минут!

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

Комментарии
Избранное Подписка Сортировка: Древо свернутое
1. grumagargler 662 30.07.18 00:09 Сейчас в теме
Подскажите пожалуйста, в статье описаны особенности и сложности перехода, но непонятно зачем вы это делали?
3. mad375 30.07.18 05:15 Сейчас в теме
Было очень интересно, спасибо
4. ihtiking 01.08.18 12:45 Сейчас в теме
Дороговато выходит.... После перехода Вы почувствовали изменения к лучшему с точки зрения бизнеса или с точки зрения ИТ ?
6. kiruha 384 15.10.18 11:05 Сейчас в теме
glassdoor.com из США обратился во франч 1С в России для перевода дата центра ?
8. zuxelzz 05.04.20 10:32 Сейчас в теме
Алексей, спасибо за статью, очень интересно.
Подскажите, пожалуйста, один момент:
"Во-первых, нужно забыть стандартную рекомендацию про создание отдельных томов для данных, логов, tempdb."

В связи с чем именно вам пришлось отказаться от этих рекомендаций? Возможно, в тексте это было написано, но, тогда значит, я не смог это понять :)
Это было связано с какими-то особенностями вашей архитектуры или просто при работе в AWS эти рекомендации не стоит принимать во внимание? Или их вообще не стоит принимать во внимание? :)
спасибо)
Оставьте свое сообщение

См. также

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

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

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

26.04.2019    10740    0    Aleksey.Bochkov    7    

Автоматическая классификация ошибок технологического журнала

Технологический журнал v8 1cv8.cf Бесплатно (free)

В статье обсудим пример практической настройки конфигурации «Мониторинг производительности» для автоматической классификации ошибок по группам/кластерам на данных текстов описания ошибок. Используем механизм векторной модели текстов и косинусное сходство между ними.

25.06.2020    1832    0    ivanov660    12    

Выбор процессора для 1С: конец споров или начало?

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

Периодически занимаясь исследованиями производительности я повидал много решений. Делюсь некоторыми выводами на основании теста Гилева и собственных мыслей.

25.05.2020    7527    0    starik-2005    216    

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Производительность и оптимизация (HighLoad) Администрирование СУБД Технологический журнал Структура метаданных v8::Запросы Бесплатно (free)

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

24.05.2020    5966    0    DataReducer    22    

Исследование технологического журнала 1С при помощи регулярных выражений в блокноте Промо

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

Все из тех, кто пробовали сдать на сертификат "Эксперт по технологическим вопросам 1С", сталкивались с методикой ЦКТП - разбор файлов технологического журнала при помощи консоли bash. Я, в свою очередь,внёс изменения в данную методику. Мне хотелось достичь более понятного вида и сфокусироваться на Perl, в качестве предпочтительного средства обработки файлов ТЖ. Вот что из этого вышло:

30.10.2017    28792    0    MrWonder    42    

Учимся готовить кроликов с редиской: опыт применения Rabbit MQ и Redis в интеграционных проектах

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

При построении мощных производительных отказоустойчивых решений для интеграции во всем мире активно используются технологии обработки очередей сообщений с помощью брокера RabbitMQ и кэш-сервера Redis. О практическом опыте использования этих технологий при построении ИТ-ландшафта, включающего системы на 1С, на конференции Infostart Event 2019 Inception рассказал Сергей Наумов.

12.05.2020    4434    0    SergeyN    3    

Ок, Лариса! Мониторинг проблем производительности с применением нейронных сетей

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

Проводить мониторинг производительности вручную, выявляя закономерности в куче графиков и десятках таблиц, довольно сложно. Но это не значит, что разбираться с инцидентами нужно только после жалоб от пользователей. О том, как обучить нейронную сеть и заставить ее оповещать о проблемах, на конференции Infostart Event 2019 Inception рассказал начальник сектора разработки ООО «Группа Полипластик» Владимир Крючков.

27.04.2020    3609    0    ivanov660    5    

Пример поиска ошибок в технологическом журнале

Технологический журнал Производительность и оптимизация (HighLoad) Бесплатно (free)

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

23.04.2020    2384    0    vasilev2015    6    

Опыт оптимизации и контроля производительности в БД с 3000 пользователей Промо

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

Данная статья написана по материалам доклада, прочитанного на Конференции Инфостарта IE 2014 29-31 октября 2014 года. Меня зовут Сергей, являюсь руководителем отдела оптимизации и производительности систем в компании "Деловые линии". Цель этого доклада – поделиться информацией о нашем опыте работы с большой базой на платформе 1С, с чем пришлось столкнуться, как удалось обеспечить работоспособность. Уверен, что вам будет интересно, так как подобной информацией мало кто делится, да и про само существование таких систем их владельцы стараются не рассказывать, максимум про это «краем глаза» упоминают участвовавшие в проекте вендоры. **update от 04.03.2016 по вопросам из комментариев

05.08.2015    60376    0    Sergey.Noskov    119    

Фреймворк "Мониторинг производительности". Руководство пользователя

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

Описание и руководство "Мониторинг производительности": краткое описание конфигурации, сборник из статей, примеров - собрано в одном файле.

21.04.2020    2793    0    ivanov660    3    

Эти занимательные временные таблицы

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

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    10038    0    YPermitin    0    

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

Производительность и оптимизация (HighLoad) WEB Интеграция Мобильная разработка Администрирование веб-серверов v8 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    11151    0    informa1555    21    

Долго открывается конфигуратор Промо

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

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015    40062    0    Gilev.Vyacheslav    1    

Многострочный контекст событий

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

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

31.03.2020    2765    0    vasilev2015    9    

Анализ взаимоблокировок

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

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

20.03.2020    4059    0    vasilev2015    21    

Многопоточность

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

Увеличиваем скорость загрузки данных в 20 раз. Как следует использовать многопоточность и готовый модуль для внедрения.

18.03.2020    6114    0    kaliuzhnyi    43    

Повышенная нагрузка на диски сервера баз данных SQL Server Промо

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

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

15.03.2015    39363    0    gallam99    17    

Улучшение пооперационного планирования в 1С:ERP 2.4 внешними средствами

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

Задача построения оптимального производственного расписания требует сравнения тысяч и десятков тысяч вариантов. Выполнять такие вычисления средствами платформы 1С Предприятие нецелесообразно. Как реализовать пооперационное планирование с использованием генетических алгоритмов и параллельных вычислений в докладе на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «ИНТЕХ» Сергей Сафаров.

02.03.2020    4413    0    ildarovich    7    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

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

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    66475    0    yuraos    112    

Делаем быстрее POSTGRESQL COUNT (*)

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

Предлагаю вашему вниманию перевод статьи Laurenz Albe "POSTGRESQL COUNT(*) MADE FAST". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/postgresql-count-made-fast/

28.02.2020    2223    0    w.r.    1    

Простое обнаружение проблем производительности в PostgreSQL

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

Предлагаю вашему вниманию перевод статьи Hans-Jürgen Schönig "DETECTING PERFORMANCE PROBLEMS EASILY IN POSTGRESQL". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/detecting-performance-problems-easily-in-postgresql/ Актуально для всех 1С ников, перешедших с MS SQL на Postgres

20.02.2020    3560    0    w.r.    4    

Планы запросов - это просто! Разбор оптимизаций запросов PostgreSQL на живых примерах

Производительность и оптимизация (HighLoad) v8::Запросы Бесплатно (free)

Проблема быстродействия 1С напрямую зависит от производительности запросов. Но как понять механику работы СУБД с помощью плана запроса? Андрей Овсянкин и Никита Грызлов на конференции Infostart Event 2019 Inception подробно рассмотрели алгоритм работы с планом запроса СУБД PostgreSQL, полученным из технологического журнала, и рассказали, на что обратить внимание, чтобы оптимизировать работу системы.

17.02.2020    8070    0    Evil Beaver    13    

Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3 Промо

Производительность и оптимизация (HighLoad) v8 УТ10 УПП1 Бесплатно (free)

Не секрет, что многие пользователи, использующие партионный учет (а таких очень много, даже среди огромных холдингов, несмотря на пропаганду РАУЗ) при больших нагрузках сталкиваются с резким замедлением списания партий.

21.06.2013    53255    0    Антон Ширяев    116    

Держи данные в тепле, транзакции в холоде, а VACUUM в голоде

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

Чтобы база работала быстро – в ней нужен порядок. Это касается как MS SQL, так и PostgreSQL. Как настроить базу, чтобы в ней поддерживался порядок, какие регламентные операции нужно проводить, чтобы данные чистились, индексы перестраивались и оперативная память высвобождалась в своём выступлении на конференции Infostart Event 2019 Inception поделился руководитель ИТ в компании «ИнфоСофт» Антон Дорошкевич. 

07.02.2020    8769    0    a.doroshkevich    17    

Оптимизатор запросов. Вторая часть

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

Продолжение статьи об оптимизаторе запросов. Во второй части мы попробуем создать свой оптимизатор и попутно разберемся с такими вопросами, как: хранение файлов; индексы; статистика.

23.01.2020    5863    0    darkdan77    59    

Улучшаем производительность 1С. Рекомендации

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

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

23.01.2020    7153    0    Kaval88    26    

Сравнение скорости работы 1C+MSSQL и файлового варианта Промо

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

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая? Затем обычно идет «флуд» на несколько десятков страниц. Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд. В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнения.

19.02.2013    53883    0    Gilev.Vyacheslav    46    

Атака сервера кнопонажималкой

Нагрузочное тестирование Инструментарий разработчика Бесплатно (free)

Чтобы убедиться, что продукт выдержит планируемую нагрузку, необходимо провести нагрузочное тестирование – написать сценарии пользовательских действий и запустить их в несколько потоков, чтобы заранее найти проблемы в бизнес-логике и «узкие места». О том, как упростить написание сценариев тестирования для конфигурации Тест-центр с помощью фреймворка Vanessa Automation на конференции Infostart Event 2019 Inception рассказал ведущий программист компании «ПервыйБИТ» Никита Грызлов.

20.01.2020    5384    0    nixel    22    

Мониторим производительность с помощью 1С RAS

Инструментарий разработчика Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Подключаемся и анализируем данные через 1С RAS. Необходимо выполнить 5 пунктов и серьезный инструмент мониторинга будет у вас в руках.

19.12.2019    9943    0    ivanov660    16    

История роста и работы команд 1С в условиях HighLoad и BigData

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

Современные потребности бизнеса заставляют программистов 1С решать все более сложные задачи. А главные требования, которым необходимо соответствовать, – вовремя поставлять ценности высокого качества. С какими сложностями приходится сталкиваться в работе программистам в динамично развивающейся брокерской сфере, и как их решают, на конференции Infostart Event 2018 Education рассказал начальник отдела интеграции БКС Технологии Сергей Артемов.

11.11.2019    6994    0    user826155    11    

Параллельные вычисления в 1С 8 Промо

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

Решение позволяет ускорять выполнение запросов в 1С 8 в отчетах путем их параллельного выполнения в разных потоках.

11.02.2013    29641    0    gallam99    19    

Весёлые картинки о работе Performance Monitor на Windows Server 2016 Std по мотивам расследования потери производительности на базе 1С

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

Данная публикация посвящена одной особенности Performance Monitor на Windows Server 2016 Std. Как понимать графики Performance Monitor на Windows Server 2016 Std при расследовании проблем в работе 1С.

22.10.2019    6965    0    EugeneSemyonov    11    

Обслуживание баз данных. Не так просто, как кажется

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

Считаете, что обслуживание индексов и статистик дело простое? Что ж, это не всегда так.

14.10.2019    16380    0    YPermitin    28    

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

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

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

30.09.2019    20687    0    YPermitin    14    

Ubuntu vs CentOS vs Win2k8 vs Debian: производительность PostgreSQL Промо

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

Хотя интернет уже переполнен статьями о "правильной" настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самую большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно. Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

03.11.2012    41838    0    madmpro    32    

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

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

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

13.09.2019    8501    0    Repich    5    

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

Администрирование данных 1С Zabbix v8 Бесплатно (free)

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

10.09.2019    17493    0    Sloth    24    

Подбор оборудования для информационных систем на платформе 1С

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

При подборе оборудования по рекомендациям с сайта ИТС возникает противоречие: проводить ли нагрузочные тесты, чтобы определить возможную нагрузку, или достаточно просто взять данные из таблиц статистики? О том, какую тактику применить в том или ином случае, на конференции INFOSTART EVENT 2018 Education рассказал начальник отдела разработки компании IBS Филиппов Евгений.

09.09.2019    8600    0    jf2000    8    

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

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

Предлагаю вашему вниманию продолжение перевода статьи 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    7136    0    w.r.    2    

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

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

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

31.08.2019    9841    2    YPermitin    7    

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

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

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

30.08.2019    10174    0    w.r.    19    

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

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

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

22.08.2019    3785    0    w.r.    35    

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

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

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

31.07.2019    7158    0    w.r.    5    

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

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

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

19.07.2019    8473    0    Филин    12    

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

Производительность и оптимизация (HighLoad) v8 v8::blocking Бесплатно (free)

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

16.07.2019    9124    0    fhqhelp    0    

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

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

Предлагаю вашему вниманию перевод статьи 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    6623    0    w.r.    19    

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

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

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

05.07.2019    4445    0    w.r.    6    

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

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

Предлагаю вашему вниманию перевод статьи 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    5250    0    w.r.    2