Опыт миграции из собственного датацентра в облако 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 698 30.07.18 00:09 Сейчас в теме
Подскажите пожалуйста, в статье описаны особенности и сложности перехода, но непонятно зачем вы это делали?
2. Aleksey.Bochkov 3474 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 3474 03.09.18 23:05 Сейчас в теме
(4) По словам CTO, в долговременной перспективе расходы на инфраструктуру после перехода в AWS ожидаются на 10-20% меньше расходов на собственный датацентр.
Изменения к лучшему заметили практически на всех уровнях:
- цикл разработки новой функциональности ускорился
- стало легче реагировать на скачки трафика (сервера приложений масштабируются горизонтально в течение пары минут)
- проще устранять проблемы
- и, как бы странно это ни звучало, сайт работает существенно быстрее в AWS.
6. kiruha 386 15.10.18 11:05 Сейчас в теме
glassdoor.com из США обратился во франч 1С в России для перевода дата центра ?
7. Aleksey.Bochkov 3474 15.10.18 20:14 Сейчас в теме
(6) я работаю в этой компании. Живу в Сан Франциско.
AQR84; Krio2; kiruha; +3 Ответить
8. zuxelzz 05.04.20 10:32 Сейчас в теме
Алексей, спасибо за статью, очень интересно.
Подскажите, пожалуйста, один момент:
"Во-первых, нужно забыть стандартную рекомендацию про создание отдельных томов для данных, логов, tempdb."

В связи с чем именно вам пришлось отказаться от этих рекомендаций? Возможно, в тексте это было написано, но, тогда значит, я не смог это понять :)
Это было связано с какими-то особенностями вашей архитектуры или просто при работе в AWS эти рекомендации не стоит принимать во внимание? Или их вообще не стоит принимать во внимание? :)
спасибо)
9. Aleksey.Bochkov 3474 06.04.20 01:46 Сейчас в теме
(8) Все, конечно, зависит от конкретной нагрузки и требований к системе, но, как мне кажется во многих случая это будет оправдано.
В AWS применяются жесткие лимиты пропускной способности как на уровне виртуальных машин, так и на стороне хранилища данных.
Например, для самых больших размеров более менее новых типов инстансов лимит пропускной способности к хранилищу составляет 2350 мегабайт в секунду.
В то же время, один GP2 том пропускает не более 250 мегабайт в секунду, а IO1 том - не более 500 Мб/с (можно до 1 Гб/с увеличить, но очень дорого).
Таким образом, для наиболее эффективного использования всей пропускной способности нужно не менее 9-10 томов GP2 или 5 томов IO1 на каждый сервер.
Если не использовать RAID0, то придется создавать 5-10 дисков и разносить нагрузку равномерно по ним, что в нашей ситуации практически нереально.
Можно использовать RAID0 и создать 2-3 логических диска, но все равно каждый из них будет ограничен пропусной способностью в 500-1000 мегабайт в секунду. Когда система испытывает повышенную нагрузку это становится узким местом.
Для нас самым оптимальным вариантом является создание единственного логического диска который состоит из 5-10 томов в RAID0 и обеспечивает максимальную пропускную способность в 2350 Мб/с. Это позволяет сгладить эффект от неожиданных пиков нагрузки.
(лимиты пропускной способности были увеличены после написания этой статьи)
Оставьте свое сообщение

См. также

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

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

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

26.04.2019    13007    Aleksey.Bochkov    7    

Parameter sniffing и генерация планов для разработчиков 1С

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

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

01.06.2021    2890    vasilev2015    13    

Ускорение реструктуризации больших таблиц. Мой вариант

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

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

28.04.2021    934    buganov    0    

Поиск причин блокировок СУБД

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

Расследование блокировок СУБД. Статья написана по мотивам вебинара Виктора Богачева.

28.04.2021    3858    vasilev2015    12    

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

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

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

30.10.2017    31666    MrWonder    42    

Тонкости эксплуатации, плюшки и особенности Postgres Pro Enterprise

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

В ходе онлайн-встречи INFOSTART MEETUP Novosibirsk Руководитель ИТ из компании ИнфоСофт Антон Дорошкевич поделился с коллегами тонкостями и опытом работы с Postgresql для 1С. 

22.04.2021    1450    a.doroshkevich    2    

Решение нестандартных проблем производительности на реальных примерах

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

На екатеринбургском Infostart Meetup выступил с докладом архитектор ИС центра разработки ФТО Александр Криулин. Он поделился с коллегами кейсами нестандартных проблем производительности и рассказал о способах их решения.

24.03.2021    3456    AlexKriulin    37    

Рецепты приготовления технологического журнала

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

Понимание принципов событий технологического журнала позволяет решать многие проблемы производительности и стабильности работы платформы 1С. О том, как взаимосвязаны события технологического журнала и как с их помощью можно анализировать серверные вызовы 1С, на INFOSTART MEETUP Ekaterinburg.Online рассказал программист 1С из компании ДНС-Ритейл Максим Старков.

22.03.2021    2632    max_st    5    

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

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

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

05.08.2015    65989    Sergey.Noskov    119    

Анализ полного технологического журнала, 100ГБ+

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

В этой статье рассматривается анализ полного технологического журнала, размер которого за 1 час достигает 50Гб+. Когда у какого-то пользователя что-то происходит, но не постоянно, и выделить определенного пользователя не получается, и проще собрать полный технологический журнал. Но на дальнейшем анализе доступные визуальные средства не выдерживают таких объемов, и просмотр журнала объемом 50Гб попросту вылетает. Но поведение 1С все же хотелось бы изучить и проанализировать, что происходит.

18.03.2021    2123    Axel2009    17    

Анализ производительности: Трассировка + Логи системного монитора

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

Небольшая заметка о том, как можно анализировать производительность при помощи собранной трассировки и показателей логов системного монитора.

16.03.2021    688    AlekseyBelyy    8    

Соединение вложенными циклами

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

Nested loops и отсутствующие индексы. Статья написана по мотивам вебинара Виктора Богачева.

12.03.2021    2816    vasilev2015    21    

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

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

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

22.04.2015    42798    Gilev.Vyacheslav    1    

Негативное влияние большого количества ролей на производительность 1С

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

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

10.03.2021    2379    aviconsult    21    

"Крест ИТ", или как жить, если у вас в ИТ ландшафте выросло Кудрово/Мурино/Девяткино

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

Добавлять новую функциональность в ИТ-ландшафт, базирующийся на тяжелых «монолитах», с каждым годом становится все сложнее. О способах преодоления проблем больших и сложных приложений на INFOSTART MEETUP Saint Petersburg.Online рассказал архитектор компании BIA Technologies Марат Шайхутдинов.

09.03.2021    870    MSChe    3    

Использование системы мониторинга Zabbix с 1С для мониторинга ключевых показателей бизнеса

Zabbix Бесплатно (free)

Мониторинг бизнес-показателей в базе 1С помогает руководителям оперативно принимать решения, реагировать на сбои, видеть реальное состояние каждого из этапов бизнес-процесса. О том, как использовать Zabbix для построения дашбордов и мониторинга ключевых показателей бизнеса, на митапе Infostart Saint Petersburg.Online рассказал Алексей Орловский.

17.02.2021    4745    orlovskiy-a    0    

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

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

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

15.03.2015    43964    gallam99    17    

Highload-оптимизация 1С: теория и практика на примере консолидированной отчетности группы "Магнит" и розничной аптечной сети "Магнит"

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

Тема оптимизации 1С на больших данных бесконечная и всеобъемлющая, поскольку на производительность влияет целый ряд факторов – количество пользователей, данных, транзакций, неоптимальные запросы и т.д. Об инструментах для локализации проблем производительности и практических кейсах оптимизации рассказал Алексей Олейник, руководитель сектора автоматизации отчетности МСФО компании «Информационные технологии Магнит».

11.01.2021    24955    user662404_itlexusss    14    

Анализ блокировок СУБД: таблица изменений плана обмена 1С

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

Практический пример анализа типичной проблемы ожидания на блокировках СУБД, возникающих при использовании планов обмена 1С. Сервер СУБД: Microsoft SQL Server.

18.12.2020    2469    zhichkin    7    

Контекст всегда важен. История проблем производительности

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

Небольшая история о проблемах производительности из-за нехватки процессорных мощностей. А также описание основных показателей работы CPU.

26.11.2020    6072    YPermitin    21    

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

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

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

22.01.2014    68539    yuraos    112    

Анализ проблем производительности по динамике мониторинга RAS 1C

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

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

07.10.2020    4230    ivanov660    12    

Ускорение медленной работы строк в 1С на примере 1С:Документооборот КОРП

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

Если у вас в 1С:Документооборот КОРП 2.1.11.5 (часть более старых и новых конфигураций): 1) Долго отправляется почта в формате HTML; 2) Медленно открывается документы внутренние / входящие / исходящие; 3) Тормозит область просмотра или открытие задач. Тогда вам сюда.

02.10.2020    4859    Nykyanen    16    

Тест скорости работы мобильной платформы 1С

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

С помощью этого приложения вы можете измерить производительность своего устройства, используя для этого мобильную платформу 1С:Предприятие. Набор действий теста полностью повторяет аналогичный тест для стационарных ПК, поэтому результаты сравнимы.

14.09.2020    1653    capitan    25    

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

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

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

21.06.2013    58590    Антон Ширяев    117    

Описание почти всех событий технологического журнала

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

Краткое описание событий технологического журнала с примерами. Все для быстрого старта.

19.08.2020    19618    YPermitin    34    

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

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

Корректируем классификацию ошибок ТЖ в процессе работы для конфигурации мониторинг производительности

17.08.2020    753    ivanov660    0    

SQL для 1С: пишем правильно, красиво, сложно

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

Многие программисты боятся работать с Null, считая, что от этих данных в запросах нужно избавляться. О том, как с помощью Null-полей в запросе решать востребованные в учете задачи по выборке данных, на конференции Infostart Event 2019 Inception рассказал ведущий разработчик ГК WiseAdvice Дмитрий Дудин.

14.08.2020    13009    dmurk    33    

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

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

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

19.02.2013    58744    Gilev.Vyacheslav    46    

Нестандартные блокировки при работе с OLAP-нагрузкой

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

Если выполнение отчета мешает работе других пользователей и провоцирует блокировки, даже с учетом «грязного чтения» – ситуация кажется парадоксальной. О том, как расследовать такие проблемы, на конференции Infostart Event 2019 Inception рассказали ведущий программист торгового дома «Петрович» Станислав Щербаков и специалист по производительности компании «СофтПоинт» Александр Денисов.

20.07.2020    2455    Филин    7    

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

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

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

25.06.2020    3575    ivanov660    13    

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

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

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

25.05.2020    21876    starik-2005    233    

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

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

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

11.02.2013    33617    gallam99    19    

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

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

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

24.05.2020    9921    DataReducer    22    

[SQL Server] Использование trace flag 9592 для сжатия траффика в кластере AlwaysOn

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

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

18.05.2020    2493    Aleksey.Bochkov    4    

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

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

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

12.05.2020    7759    SergeyN    3    

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

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

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

03.11.2012    45050    madmpro    32    

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

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

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

27.04.2020    4811    ivanov660    5    

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

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

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

23.04.2020    3615    vasilev2015    7    

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

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

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

21.04.2020    4401    ivanov660    3    

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

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

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

06.04.2020    14505    YPermitin    0    

Оптимизация запросов 1С посредством индексации временных таблиц. Миф? Тестируем, смотрим, считаем

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

Появилось свободное время, решил проверить на работе индексацию таблиц. Решил поделиться с Вами результатами исследования. Давайте порассуждаем на эту тему? Часто ли вы пользуетесь индексацией в запросах? Платформа 8.3.16.1224

03.04.2020    6988    feva    15    

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

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

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

31.03.2020    15060    informa1555    35    

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

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

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

31.03.2020    3587    vasilev2015    11    

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

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

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

20.03.2020    6258    vasilev2015    27    

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

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

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

18.03.2020    8210    kaliuzhnyi    44    

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

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

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

02.03.2020    6408    ildarovich    8    

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

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

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

28.02.2020    3866    w.r.    1