Конфигурации 1С: Предприятие 8.3 Управление торговлей 11.2, Бухгалтерия 3.0. Есть еще Управление персоналом, но она маленькая.
Данный комплекс охватывает все сферы учета торгового предприятия.
«У нас будет сервер с SSD, и все будет летать». С этой фразы начинаются проблемы, если подойти к делу без творчества, надеясь только на быстродействие железа.
Процесс перехода на новую конфигурацию Управление торговлей сложен и тернист. Преимущества новой конфигурации компенсируют проблемы возникающие в результате модернизации информационной системы. В конфигурации Управление торговлей 11.1 или 11.2 заложено много интересных возможностей. Это конструктор, из которого можно сделать много всяких систем. Для нужд конкретной организации нужны не все сервисы предоставляемые конфигурацией. Перед принятием решения о переходе на новую конфигурацию нужно составить план, какие системы будут использоваться. Сразу все сервисы внедрить не получится. Нужно будет пройти путь, из-за которого будет много суеты и беспокойства. Есть бонус, некоторые удобные, нужные возможности новых технологий войдут в работу легко и непринужденно.
Торговая организация решила улучшить свою информационную систему Управление торговлей 10.3. Без конфигурации Бухгалтерии конфигурацию Управление торговлей рассматривать неверно. Это комплекс программ и как правило используются вместе. И чаще всего обмениваются данными, по крайней мере в сторону Бухгалтерии.
Бухгалтерию модифицировали первой, запустили Бухгалтерию предприятия 3. Главный бухгалтер грамотная, справилась практически самостоятельно, за что ей огромная благодарность.
Старая информационная система использовала сервер терминалов, компьютеры пользователей малопроизводительные. Подключение к базам 1С толстым клиентом, обычные формы. Удаленные пользователи подключались к терминалу. Все было привычно и работало в рамках своих возможностей для коллектива примерно 15 человек.
Нашлись в компании буйные головы, заговорили о новых возможностях УТ 11.1, развитии бизнеса и новых системах контроля за деятельностью организации. А жизнь была такая спокойная. Взгрустнули и начали.
Тестирование показало, что для новых конфигураций требуется больше ресурсов оперативной памяти и процессора сервера. Расчеты показали, что при переходе на новую информационную систему, сервер «ляжет».
Решили использовать тонкий клиент 1С Предприятие на рабочих станциях пользователей. Ресурсы сервера и рабочих станций будут использоваться эффективнее, некоторые вычисления перейдут на рабочии станции пользователей, что немного разгрузит сервер.
Использовать файловый вариант базы с толстым клиентом 1С Предприятие отказались сразу. Сеть даже 1 Гбит/с, файловой базой данных используется неэффективно Для передачи данных от базы к пользователю, при формировании запросов, передается большое количество данных, обработка происходит на компьютере пользователя, а они напоминаю слабо мощные и не подходят для обработки больших массивов данных, а работают только для отображения интерфейсных объектов. Несколько одновременных запросов к данным вызывают раздражающие задержки ответа.
Для оптимизации расходования денежных средств немалую сумму решили растянуть во времени. Размер базы, после запуска в эксплуатацию, небольшой и казалось вполне можно обойтись без сервера 1С Предприятия. Apache Web сервер на Windows не показал высокого быстродействия. IIS web сервер показал более высокое быстродействие. Настроили доступ Web сервера, к файловой базе.
Необычно получилось, но работает. При небольшом количестве пользователей, вполне работает. Дешево получается. Управляемые формы работают отлично.
Запустили в эксплуатацию конфигурацию Управление Торговлей 11.1 и Бухгалтерия предприятия 3. Пользователи к базе подключались через Web подключение, тонким клиентом. Нагрузка на локальную сеть минимальна. Удаленные пользователи подключаются к базе без проблем. Счастье было недолго.
Доступ к старой базе УТ 10.3 тоже был нужен, пришлось по одному пускать в терминал. Терминал расходует ресурсы сервера не оптимально, на каждого пользователя выделяя ОЗУ и запущенные приложения нагружают процессор сервера, а он итак сильно загружен обработкой запросов баз данных.
Первое впечатление пользователей после перехода от обычных форм к управляемым, что все тормозит. Формы открываются и перерисовываются медленне, отчеты отрисовываются медленее. Немного поработали, привыкли, оставили суету в прошлом.
Вторая засада ждала при исполнении регламентных заданий. В таком виде сервера, они выполняются не на сервере, а на рабочей станции пользователя в фоновом режиме. Все вроде работает, но сильно тормозит, пока подойдешь задание заканчивается и все работает нормально. Пользователь показывает, а уже не тормозит. Отходишь опять тормоза, просто магия.
Интерфейс УТ 11.1 явно разработан под Full HD 1080, при меньшем разрешении формы на экране не умещаются. Началась замена мониторов по офису. Пользователи это подержали.
Пока разобрались, откуда тормоза, поменяли сервер на более мощный, не помогло. Организация прибавила 10 человек и пользователей стало 25. Активных пользователей. Постоянно формируют отчеты, выписывают проводят, перепроводят документы. Жизнь закипела. И тормоза информационной системы совсем не нужны.
Поняли, что обойтись без сервера 1С Предприятие не получится. Купили x64 сервер. Вещь! Отличное программное обеспечение, моя благодарность разработчикам.
Выбрали PostgreSQL. Во первых это недорого! Во вторых отлично работает. Альтернативы у нас были, но бесплатно нас привлекло больше всего. Рассказы о тормознутости PostgreSQL под Windows посчитали наговором.
Другое преимущество PostgreSQL в том, что сервер может ставиться на Windows для рабочих станций. Очередное желание экономии. Работает по сей день, больше года. Примерно раз в 20 дней перезапускаем «сервер» в плановом режиме. Windows Server работает надежнее, но у торгашей деньги важнее, а ITшники пусть думают как это будет бесперебойно работать, а иначе за что им деньги, и немалые деньги, платят. Показатель доступности сервера: с 9:00 — 18:00 пн-пт 100%, остальное время 98%.
Общество платит инженерам деньги не за многие знания, а за снижение стоимости решения проболем и построение более эффективных и недорогих механизмов и систем.
Вот оно Счастье! Регламентные задания выполняются на сервере, работает быстро. Ложка дегтя в виде тормозов нашлась, периодически, в отчетные периоды в налоговую инспекцию, возникали тормоза работы баз торговли и бухгалтерии. При загрузке данных в тестовые базы все вообще практически останавливалось. Пришлось для экспериметов и других регламентных операций, выбирать нерабочее время. Это послужило хорошей мотивацией для решения проблем.
Решение нашлось очевидное. Перенести Управление Торговлей 11.1 на отдельный SSD накопитель, отдельно от остальных баз. Полегчало, все довольны. Размер базы вырос многократно до этого момента и ее размеры стали впечатлять .dt файл выгрузки 4 Гб. Пару месяцев все шло отлично, отторговали Декабрь.
Спокойная жизнь в очередной раз оказалась под угрозой. Решили обновить УТ 11.1 на УТ 11.2. Свертку данных решили не делать, «нельзя» удалять ценные статистические данные, которые необходимы при планировании закупок и продаж. Обновлять без свертки — это крупная ошибка! Учет мы вели немного нестандартно. За год создали более 20 000 позиций номенклатуры с огромным количеством дополнительных реквизитов. Переход был очень болезненным, начался в новогодние каникулы, полностью привели в порядок базу к Марту.
Новые возможности Управления Торговлей 11.2 порадовали. Интерфейс форм документов изменили и заточили его под мониторы с меньшим разрешением чем 1902х1080. Казалось жизнь наладилась, но снова начала тормозить база. Отключил относительно ненужные регламентные задания. Стало легче. Но быстродействие стремительно падало с быстрым ростом базы, в которую начали заливать много файлов, картинок, документооборот вырос. Стало нужно решить проблему быстродействия с учетом возрастающей нагрузки.
С увеличением торговли, подросла и бухгалтерия. Номенклатуры в нее тоже много попало, количество документов увеличилось. Почти катастрофа.
Детальный анализ работы сервера показал, что PostgreSQL пишет много служебных данных на накопитель. Файлы транзакций, логи и прочая информация пишется в большом количестве. Размеры запросов явно стали больше. Очередь на обслуживание к накопителю выстраивалась до 10 секунд. Начал думать что зря связался с PostgreSQL по Windows.
Изменил настройки PostgreSQL. В файле .conf настройки по умолчанию выбирались давно и они не заточены под компьютеры с ОЗУ 32 Гб. Размеры кэшей увеличил, лучше не стало.
Напросилось решение выделить отдельный накопитель для SQL сервера.
Очередь на обслуживание пропала. Заработало все хорошо, но только у пользователей с полными правами. У пользователей с ограниченными правами тормозить стало меньше, но разница в скорости была заметна и существенна.
Замер производительности показал, что разница во времени сохранения данных во временное хранилище 1С, составляет 18 раз. Это много. Методами проб и ошибок выяснил вид объекта, который влияет на производительность. Объект Документ. Поленился выяснять какой конкретно вид документов оказывает влияние на быстродействие. Дал всем пользователям права на чтение всех документов. Скорость работы пользователей возросла. Началась нормальная эксплуатация. На текущий момент счастье продолжается.
В результате:
SSD 1. Windows и установленные некоторые программы могут загрузить пропускную способность канала передачи, но с помощью настроек и большого количества оперативной памяти можно от этого избавиться. Сервер 1С Предприятие пишет логи, журналы баз данных. Иногда очень активно.
SSD 2. PostgreSQL создает файлы транзакций, ведет большое количество журналов. Гипотеза: что с ростом количества баз, больших баз, растет нагрузка на этот накопитель.
SSD 3. Большая база данных торговли лежит на отдельном накопителе, для обеспечения максимальной скорости доступа.
SSD 4. База бухгалтерии не столь критична к задержкам и пользователей у нее меньше. При массовом перепроведении документов за большой период, требуется высокое быстродействие. Остальные базы не имеют больших размеров. Тестовые базы активно не используются в многопользовательском режиме.
Тест Гилева для такой конфигурации сервера показал результат более 60. Тест проводился в середине рабочего дня, во время теста у пользователей задержки не ощущались.
Что делать, если опять будет тормозить?
Вероятнее всего это будет связано с очередью на обслуживание к накопителям. SATA SSD работают со скоростью 500 МБайт/с. PCI-E SSD накопители работают со скоростью 1800 МБайт/с — скорость можно увеличить в 3 раза.
Вывод: система работает.
В настоящий момент 25 пользователей, сервер работает с большим запасом быстродействия. База данных торговли PostgreSQL имеет размер 18 Гб, .dt базы 7 Гб. Сервер имеет на борту 32 ГБ ОЗУ, процессор I7 4770 3.4 ГГц.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
хм.. а где собственно особенности — кроме как работа на «псевдо серверном железе с псевдо серверной операционкой»?
Название статьи можно менять на другое — Как в попытках экономить (не относится к PostgresSQL) мы имеем проблемы с производительностью.
(1) caponid,
Правильно, Достоевский пусть поменяет название «Преступление и наказание» на «Пособие по убийству старушек», а «Идиот» заменит на название «Комментатор на Инфорстарте».
Если при прочтении у Вас возникли мысли (удачный вариант), это необязательно мысли автора статьи. Вы увидели, то что увидели. Это Ваши мысли, напишите статью и тогда расскажите свои.
Небольшая поправка: На отдельный жёсткий диск надо выносить журнал транзакций PostgreSQL.
Теперь немного по статье:
1. Картинки, сканы документов и прочее в этом роде необходимо хранить на отдельном, можно медленном, диске, а не увеличивать базу данных. Для хранения файлов отдельно в УТ 11 встроен специальный инструмент.
2. Судя по вашей итоговой картине у вас нет зеркалирования дисков и про бекапы вы ни чего не сказали. Итог будет очень плачевен.
3. «Дал всем пользователям права на чтение всех документов», дали бы сразу административные права всем, зачем париться с правами доступа *поднял табличку «сарказм»*
Какими средствами измеряли быстродействие? Вопрос не праздный, на нашем сервере стоит апач в связке с 1С мини и постгрес, пользователи работают через веб не в локалке в тонких клиентах, правда пользователей всего 5, может на таком количестве особой нагрузки не почувствуешь…
Тоже есть в планах обновление, свёртка не рассматривается в принципе. На какие грабли наступили при обновлении? У нас база 35Гб, резервная копия делается средствами постгре, сколько выгрузка средствами 1с весит не пробовали выяснять… Закрытие месяца делается несколько часов.
(3) Dragonim,
В зависимости от поставленной задачи гут быть разные варианты. Сложно утверждать, когда не ясна полная картина.
Ясное дело резервное копирование выполняется. Делается средствами 1С. Мне понравилась поговорка: администраторы делятся на две категории: те кто делает бэкап и тех кто скоро будет делать бэкап.
(4) mythos,
Монитор ресурсов Windows. Суть в том, что при наличии севера 1С Предприятие Web сервер не играет столь важной роли в обработке данных. Иначе в варианте когда Web сервер обрабатывает запросы к базе данных.
Очень долгое обновление справочника номенклатура.
Были документы реализации «регламентный учет». Движения по ним сильно изменились. После обновления были проблемы с резервами товаров, взаимозачетами с клиентами.
Ошибки в некоторых формах (обновление было до 11.2.3.66).
База PG 18 Гб, выгрузка .dt 7 Гб. В моем варианте, средствами PG очень долго делается и может закончится ошибкой.
(4) mythos,
В моей конфигурации минут за 5 1 месяц закрывается. Ситуация такая, что задним числом регулярно правят документы и закрывать месяца (2-5 обычно) приходится по несколько раз в день.
(3) Dragonim,
Несомненно это большая проблема, уровень отказоустойчивости низкий. RAID не используем намеренно.
Отказоустойчивость отдельная тема. Очень дорогостоящая и сложная. Пока проще заменить оборудование полностью, чем резервировать.
Мы надеемся в случае выхода из строя сервера, восстановить из резерва. Проводили «тренировки», час другой простоя сервера, только внесет свежую струю в коллектив.
Реляционные базы данных не предназначены для хранения бинарных данных. От того что они это могут делать, не значит что это стоит делать. Лучше замедлить доступ к файлам чем замедлить всю базу данных и увеличить её объём.
Я не знаю не одного средства встроенного в 1С которым можно делать резервные копии баз. Выгрузка баз в dt файл не считается резервированием. В вашем случае необходимо делать резервные копии средствами базы данных.
Отсутствия рейда приводит к последствиям потери всех данных от момента отказа, до последнего бекапа.
«Поставить новый сервер, установить и настроить его, подключить к системе» за 1 час???? Я бы на это посмотрел.
(9) Dragonim,
Пробовал, делается неприемлемо долго. И восстанавливается через раз.
Распространенное мнение. Однако dt отлично восстанавливаются.
Иногда RAID глючит, последствия ужасны, если контроллер принимает решение восстановить копию с убитого накопителя. Я с этим несколько раз сталкивался.
Залог быстрого восстановления сервера (1-2 часа) — это SSD накопители и резервное копирование всех носителей системы.
Нет, ну а в чем особенности-то?
про табличные блокировки в файловой базе вы не знаете
про режимы wal вы не знаете
про искоробочную репликацию PG вы не знаете
про распухание таблиц вы не знаете
про специфику RLS и порядок ее анализа на pg вы не знаете
По сути вы распараллеливаете нагрузки на IO по разным шпинделям, не зная о том, что нормально функционирующий сервер СУБД не задерживает выполнение запросов на IO.
Настройки Postgres делали? Можно conf в студию? Желательно, прикрепить к статье. На стоковых настройках Postgres не то чтобы «лагает», но очень не оптимально работает.
Не ясен режим блокировок, который выставлен в конфигурациях. Postgres это не блокировочная СУБД и настройки блокировок в 1С должны быть соответствующие.
Если это не указать, то я могу сказать, что у Вас полностью не настроенная система и все Ваши SSD абсолютно бестолковая трата денег.
P.S.: Не надо RLS — отключите RLS.
(11) asved.ru,
Статья написана для широкого круга лиц популярным языком и без заморочек. Цель доступно объяснить и сразу применить в жизни.
(12) karapuzzzz,
Блокировки не изменял, что стоит от производителя конфигурации, то и осталось.
Conf почти без изменений, что могу вспомнить: shared_buffers = 512MB # min 128kB. После этого стали живее исполняться большие запросы.
Может чего еще менял, но не думаю что это оказало сильное влияние на работу.
Версия PG 9.4.2-1.1C
(13) вообще — на здоровье, к таким как я больше заказчиков придет 🙂
(15) asved.ru,
Заказчики любят объяснения попроще, а иначе просто непонятно.
Если я буду заказчиком, то обращусь к Вам за советом.
(16) заказчик платит не за объяснения, а за качественно работающую информационную систему. Соответственно нужда в объяснениях отпадает. Ну или за отдельную плату без гарантии понятности неспециалисту, но на моей памяти никто такого не хотел.
(17) asved.ru,
Перед созданием системы нужно объяснить, что получится и как это работает. Главное не перебрать с терминологией. Если на лбу заказчика появляются складки головной боли, то скорее всего он уже не заказчик.
Нужда в объяснениях есть всегда. Просто так деньги никто не отдает, как минимум хотят аргументы в пользу системы. У нас рыночные отношения и у заказчика есть выбор: работать с тем занудой или с тем общительным, толковым парнем.
Поэтому на мой взгляд менеджеры по продажам не должны обладать излишними знаниями, они им только вредят, но в тоже время в вопросах разбираться нужно.
При написании статей нужно учитывать, что основная масса читателей специалисты в других областях и слишком много подробностей усыпят их внимание.
Как по мне нужно статьи чтоб было написано: быстро, четко, действенно (и картинок побольше). Остальное можно причитать в технической документации к программному продукту.
(18) см. (15) 🙂
(10)
Это как? Контроллер решений не принимает.
(20) milo1,
Хм, а кто принимает в RAID решение о том какая копия данных актуальна?
Например, в RAID на одном из накопителей обнуляется FAT. Запись определяется как более новая, на остальные накопители транслируется информация о изменениях. Результат: данные недоступны.
(11) asved.ru,
порекомендуйте, пожалуйста, литературу или ресурсы откуда можно почерпнуть всю эту информацию.
больше похоже на антирекламу. Из серии «как делать не надо». Или за что мы все таки платим в серверных решениях
(24)
Я уже заметил по ответам, что любое мнение, которые не соответствует мировоззрению автора жестко им минусуется, прям комплексы какие — то. Есть два мнения, автора и неправильное 🙂
У Вас в тестах может и по одному работает. У меня 50 активных пользователей.
Знали бы архитектуру 1С, RLS, настройки темповых баз — Вас бы ничего не удивляло.
Вкратце: Статья — советы, как делать не надо.
(26) alexlights,
Минус я поставил за Ваш пост, потому что пост явный выпендреж и не по той конфигурации.
Пользователи только тестированием и занимаются? 10 баз по 50 пользователе = 500, явно не соответствует действительности.
(25) adapter,
Пост больше похож на троллинг лишь бы привлечь к себе внимание.
(26) alexlights,
Не соответствует действительности. Советы в конце статьи, видимо до конца Вы не дочитали. В статье перечислены ошибки, которые легко совершить.
Минуса за посты Вами заслужены.
Коллеги, надо поднять рейтинг статьи. Благодаря таким неучам, у нас есть работа 🙂 Пусть больше человек внемлет советам мегаспециалиста дантиста — проктолога.
(30) alexlights,
И это говорит человек не написавший НИЧЕГО, кроме бессмысленного комментария.
Бгг, клиент-серверная база масштабируется лучше файловой, а постгри для лучшей производительности надо настраивать. Прямо открытие Америки
Рассуждения насчет падающего рэйда так вообще заставляют хохотать в голос. Спасибо, повеселили
Ну и напоследок совершенно непонятно почему был куплен х64 сервер при том, что намного эффективнее было бы купить сервер х32, а разницу вложить в железо. Да хоть в ту же оперативку.
(32) 1С_Мастер,
х32 больше 4 ГБ ОЗУ не использует, какой смысл вложиться в оперативку? Необдуманный вредный совет, минус к карме.
(32) 1С_Мастер,
Пожалуйста. Весело это когда из RAID пропадает вся информация. Если не сталкивались, от этого веселитесь, когда случится, не весело будет.
Это не рассуждения — это опыт.
(33)
А вы анализировали сколько оперативки у вас на данный момент потребляет один рабочий процесс сервера предприятия? Если он у вас вдруг вдруг сожрал больше четырех гигабайт памяти, я бы посоветовал поменять настройки, чтобы добавилось еще несколько процессов. Ограничение по оперативке идет именно на один рабочий процесс, а одному рабочему процессу четырех гигабайт за глаза. Как писал Гилёв (Возможно я ошибаюсь и это писал не он, пруф искать лениво), разница в производительности между х64 и х32 версиях сервера будет заметна только на действительно больших базах (ваша же сейчас меньше 20ГБ и большую ее часть составляют картинки) и будет в пределах 5-10%
«Зачем же много оперативки?» спросите вы. А для постгреса, он ее очень любит и любит кэшировать таблицы в оперативной памяти. Чем больше свободной памяти вы ему дадите, тем больше возможностей для кэширования, тем быстрее исполняются запросы.
PS. Вы очень любите плеваться минусами в карму, не надо так. Если вы плюнете в комментаторов, комментаторы утрутся. Если комментаторы дружно плюнут в вас, вы утонете.
Это не рассуждения — это опыт.
Статистика беспощадна. Проблемы с жесткими дисками происходят куда чаще, чем с рэйд контроллерами, а наличие рэйда не избавляет вас от обязанности делать бэкапы. Но если вы так уж не доверяете аппаратному рэйду, есть программный. Точных данных у меня нет, но вызывающее доверие админы говорили о его исключительной надежности.
(35) 1С_Мастер,
Я также охотно ставлю плюсы.
Отвечу на некоторые Ваши вопросы:
1. База уже немного больше 21 Гб.
2. Сервер 1С предприятия играет не последнюю роль и о его производительности тоже нужно заботиться. В данный момент он потребляет 3.3 Гб ОЗУ (перезапуск был 02:00 сегодня, утро пятница, пользователи вялые). Иногда, при больших нагрузках он 10 Гб ОЗУ употребить может. Если долго не перезапускать, то постепенно много памяти под себя закэширует (от настроек зависит). Я по ночам перезапускаю сервер 1С Предприятие (не целиком компьютер), так надежнее работает.
3. Выборка на сервере идет в основном из памяти, это несомненно ускоряет работу. На последнем скриншоте в статье снимок монитора ресурсов, там видно, что не найденных в памяти страниц около 20%.
(33)
Вы меня простите, конечно, но про рабочие процессы вы в курсе?
(36) 1С_Мастер,
У меня не стоит задача абсолютно бесперебойной работы, с горячей заменой деталей сервера. Перерыв в несколько часов неприятен, но не критичен.
При другой задаче, я бы рассмотрел и другие варианты решения. И не только RAID, но и репликации.
Выдерните из нее таки картинки, не дело их хранить в базе
Рабочие процессы же. У меня сейчас семь рабочих процессов сожрали совместно 12 ГБ озу. На х32 сервере. На х64 они потребили бы примерно столько же. А разница в стоимости лицензии двукратная
Если диск сдохнет у вас в конце дня, а бэкап делался ночью, придется как-то восстанавливать всю работу за день. Не смертельно, но приятного мало
(41) 1С_Мастер,
Это приемлемый ущерб, к нему готовы.
Зря советуете не зная всех деталей.
Вернемся к х32-х64:
Сервер 1С Предприятие х64 умеет занимать ресурсы процессора более одного ядра. Когда ему надо он берет много ресурсов и быстро работает.
х32 занимает ресурсов не более ядра.
Например: я запускаю какой нибудь невероятный отчет на восьми-ядерном сервере. На сервере х64 будет на этот процесс будет выделено 40%, при х32 на процесс выделится 12,5%. Разница в скорости формирования отчета будет соответственная.
Ключевое слово тут «Невероятный». Даже если этот отчет тянет данные из всех таблиц базы за весь период ее существования основная нагрузка ляжет на БД, на постгрес. Если отчет написан разумно, без каких-то безумных вычислений на стороне сервера предприятия.
Я не спорю о том, что х64 сервер производительней. Конечно, он производительней. Но разницу в производительности вы заметите когда база у вас перевалит за сютню гигов. (В вашем случае за 5 сотен ибо ситуация когда бэкап базы весит едва ли не в половину от самой базы ненормальна)
(43) 1С_Мастер,
Не в размере дело. Объединения таблиц, выборка за большой период, регистры в миллионы записей нагрузят и сервер 1С Предприятие и PG.
Любопытно, обоснуйте пожалуйста это утверждение.
«-«,»+»
Очевидно же. Бэкап це по сути архив с базой. Данные из таблиц обычно сжимаются очень хорошо, картинки и видео сжимаются очень плохо. Поэтому, перенеся картинки во внешнее хранилище вы добьетесь не только того, что сама база похудеет наполовину, но и того, что бэкап будет весить в десятки раз меньше, около 2-3% от объема самой базы. Ну и скорость с которой делается бэкап возрастет, что тоже важно, иначе можно дорасти до ситуации, когда за ночь резервная копия сделаться не успевает.
Объединением таблиц занимается СУБД, как и выборкой. Сервер предприятия же, если упрощенно, строит план запроса, отдает субд, принимает и обрабатывает результат. Конечно, результат тоже может содержать многие миллионы строк и на их вывод в табличный документ потребуются долгие часы. Но кому, простите, понадобится отчет из многих миллионов строк? Кто эти миллионы строк будет изучать и анализировать? И чем тут поможет та самая многопоточность? Вывод результата выборки в отчет все равно будет идти в одном потоке
Чтобы быть полностью объективным, хочу добавить что мои рассуждения о связи х64 сервера и объеме базы достаточно поверхностные. Первостепенен тут не скорее не объем базы, а количество одновременно пользователей и их активность, но обычно с большими базами работает много пользователей, а с маленькими мало, поэтому я говорю именно с точки зрения объема, чтобы не усложнять дискуссию лишними подробностями.
Попробуйте сжать dt архиватором. Увидите, что не очень-то и сжимается. И да, бэкап с помощью dt це моветон. Не спорю, он удобен, но dt не предназначен для бэкапа, делайте бэкапы с помощью субд.
Чаще нужно обработать миллионы строк и вывести несколько.
Разумный разработчик предоставит обработку миллионов строк СУБД
Вывод о большом количестве картинок я сделал исключительно из вашей информации о размерах бэкапов, которые могут быть настолько большими именно по причине большого количества плохо сжимаемых данных
Это не баян, это тот самый опыт
А почему не сжимается? Да потому, что уже сжат. И если 20 гигов по сути текстовых и числовых данных не могут ужаться до 200 Мб, есть там что-то еще кроме текста и чисел. Что же это?
Кому нужен такой разум?
Ну, работодателям обычно нужны специалисты способные решить задачу оптимальным способом, а не тем, который требует перебора миллионов строк.
(50) 1С_Мастер,
Скорее наоборот. Базы содержат данные о важных частях работы организации и ничего работодатель из этого ни потерять, ни пропустить не хочет. Про перебор строк это Ваши размышления, ясное дело что обработка идет по индексам, промежуточным итогам и пр.
У меня опыт о .dt только положительный. Восстанавливается почти гарантировано, довольно быстро, переиндексируется при загрузке. Компактное хранение данных. Нельзя выгрузить не в монопольном режиме (это спорно, но надежнее и спокойнее). Периодически проверяю распаковывается ли бэкап, разворачиваю в базу разработки свежие бэкапы. Пока сбоев не было. Скорость выгрузки выше, чем скорость выгрузки из PGAdmin III.
Какой Ваш опыт?
Вот признайтесь, вы меня троллите?
В дополнение к бэкапам средствами СУБД я делаю дампы в dt, т.к. это действительно удобно, отрицать описанные вами преимущества я не буду. Если надо развернуть базу из копии первым делом разворачиваю из дт. Получается не всегда, достаточно часто вылезают проблемы с уникальными индексами. Точную статистику не веду, ни к чему она мне.
Очень часто подобные проблемы случаются при переводе в клиент-серверный вариант файловых баз (тут много зависит от возраста базы, чем база старше, тем выше вероятность чего-то нехорошего). Да и тут, на инфостарте очень много похожих случаев описано, почитайте хотя бы вот это
(52) 1С_Мастер,
Я думаю что это вы троллите. Много $m за посты в этой начислили?
У меня есть такая база, .dt из нее не делаются, тогда средствами SQL ее таскать приходиться. Но она не очень большая и PGAdmin реально дождаться.
С рабочей базой проблем нет, .dt отлично выгружаются и загружаются.
Какие-то крохи, 1 или 2 sm. И да, я искренне стараюсь не сорваться с простого сарказама на троллинг
Будет обидно, если дамп из dt откажется загружаться как раз в тот день, когда навернется жесткий диск
(54) 1С_Мастер,
Статьи писать немного выгоднее :).
За это плюс от меня лично.
Сервер 1С Предприятие х64 умеет занимать ресурсы процессора более одного ядра. Когда ему надо он берет много ресурсов и быстро работает.
х32 занимает ресурсов не более ядра.
Например: я запускаю какой нибудь невероятный отчет на восьми-ядерном сервере. На сервере х64 будет на этот процесс будет выделено 40%, при х32 на процесс выделится 12,5%. Разница в скорости формирования отчета будет соответственная.
Бред. Даже не буду пояснять, почему. Учите матчасть.
Решение о сервере x64 действительно правильное, но исключительно в силу ограничения x86 процесса по памяти. Частенько бывают ситуации, когда файловая БД или сервер x86 не могут прожевать достаточно большой набор управляемых блокировок, падают по недостатку памяти. Наиболее частый пример — замена значений средствами БСП.
Это не баян, а официальная документация 1С. Которую Вы поленились прочитать.
По поводу размера pgdump 1С_Мастер скорее всего прав.
Это база, состоящая в основном из коротких числовых значений.
С другой стороны лиц, заявляющих о прямой связи размера базы с ее быстродействием, нужно гнать из профессии ссаными тряпками.
(22) mythos, начните с сайтов postgrespro и postgresql.leopard.in.ua
(56) asved.ru,
Обозначая dt не как резервное копирование, 1С снимает с себя ответственность на случай потере данных. А иначе по судам затаскают.
(56) asved.ru,
Все так говорят, когда аргументов нет, а сказать очень хочется. Я думаю Вы либо пьяны, либо обижены. Ну, и без минуса от меня, Вам никак не обойтись
(51)
Можно только ещё раз посоветовать разобраться с настройками PG и системы целиком.
Я последние два года периодически занимаюсь восстановлением баз 1С, плюс администрирование, и мой опыт как раз говорит что .dt — не лучший вариант.
«Восстанавливается почти гарантированно» — полно случаев когда играет именно это «почти». Самое частое — проблема с неуникальными значениями при переносе из файлового варианта в MS/PG SQL, но не только.
Сразу уточню, я предпочитаю pg_dump в .sql.bz2 (через lbzip2 на linux’е) — и поправить можно при необходимости, и diff можно делать, и сжимать можно. На скорость никогда не жаловался. В первый раз слышу чтобы дамп мог не сняться — у нас используется в PG база на 20+Гб без сохранения двоичных данных.
«Довольно быстро» — восстановление средствами pg на моем опыте было быстрее чем из .dt
Необходимость монопольного режима я воспринимаю скорее как минус
Реиндексация проходит аналогично
Да, проверку разворачиваемости бекапов делать надо вне зависимости от способа создания бекапа, но сбоев больше было с .DT
(10)
Я что-то с трудом вспоминаю, как контроллер может «принять решение восстановить копию», при том условии что у них понятия «копии» отсутствует.
Если конечно использовать дешевые софт-контроллеры, и встроенные в ОС средства, то такие результаты возможны, но опыт показывает это кривые руки или не знание элементарной матчасти.
Ну и используйте железные рейд-контроллеры, это лучше и дешевле одного дня работы фирмы.
Опыт интересный, так как занимаюсь щас внедрением УТ11.2, но такую схему очканул бы делать.:)
(63) kostyag,
Мой отрицательный опыт именно на аппаратных контроллерах.
Странно, но комментарии есть прямо противоположные. Кто говорит о софт RAID и рекомендует использовать их, а кто о аппаратных. Видимо сказывается недостаточный опыт оппонентов в использовании оборудования.
Какую схему планируете использовать?
(49)
Баян это комментарии типа: «у меня .dt всегда загружался и проблем не было». А у вас сколько баз на обслуживании?
У меня больше 200. И ситуация когда из dt база не загружается стабильно бывает 1-3 раза в квартал. Что не так уж и мало….
И читайте документацию 1С в которой всё это описано.
(49) У меня .dt обычно занимает до 10 процентов от объема бд. На любых базах, торговля, БГУ, ЗУП- но эти обычно не очень большие. Резервирование посредством выгрузки .dt имеет место быть но в основном на файловых базах, да и использование обычных архиваторов в этом случае намного предпочтительнее.
(66) VampirRo,
В некоторых компаниях этот вопрос задают на собеседованиях. И после бэкапа файловой базы в dt пойдёте искать другую работу.
(21)
Никак он не определяет. Это не его задача, если диск отвечает на команды и запросы, значит он исправен.
Никакая запись как более новая не определяется контроллером. Вы представления не имеете как происходит запись на диски. Тем более как работают современные контроллеры.
Если у вас там что-то где-то обнулилось (читай пришла команда на запись), значит изменения будут внесены и на другие диски. Нужна система с контролем корректности данных от «тихого» повреждения — ставьте сервер с ZFS для данных. А еще лучше все критичные данные бэкапируете в зависимости от разрешенного времени простоя.
(69)
Если у вас контроллеры решают какие данные новые, а какие старые — это неудивительно.
(70) milo1,
Кто у вас решает, какие данные новее?
(64)
Я бы изначально использовал RAID10. 🙂 Или хотя бы RAID1.
Странно, но комментарии есть прямо противоположные. Кто говорит о софт RAID и рекомендует использовать их, а кто о аппаратных. Видимо сказывается недостаточный опыт оппонентов в использовании оборудования.
Не все контроллеры, конечно, одинаково полезны. Но большинство проблем именно от неправильной настройки, либо действий сотрудников которые умудряются втыкать/вытыкать убитый винт, либо полностью игнорировать разваленный рейд.
Давайте начнем с того, что ОС не видит винты как таковые, она работает с контроллером. Для неё контроллер это такой жесткий диск и ей в целом пофигу как и что там происходит. Так что если вы обновили данные в системе, то контроллер просто запишет данные на жесткие диски в соответствие с внутренними настройками.
Поэтому и контроллер ничего не решает, он просто пишет и следит за состоянием.
Я слышал про истории когда винт сыпался, а контроллер продолжал работать с ним, но такие истории остались давно позади.
Это просто треш какой-то, а не обсуждение. Где-то на середине хотел написать что-то типа «спасибо всем, поржал», но дочитав до конца просто устал. Вообще, поведение автора, я лично оценил как троллинг, возможно потому, что я полагаю, что люди не бывают настолько неквалифицированы и у упорны в отстаивании очевидных глупостей. По крайней мере в таком узком сообществе как ИС.
Впрочем еще вчера был свидетелем подобной перебранки двух людей, когда один человек вел конструктивный диалог, а другой откровенно «тупил». В итоге закончилось так же — срачем и взаимной обидой. Хотя одного из участников я еще в начале спора предупредил, что «тролль детектед», но к концу беседы, я уже начал сомневаться. А вдруг действительно бывают такие люди которые не троллят, а действительно так считают? Ведь есть же тек, кто верят, что кусок мяса съеденный в пост приведет их в ад, а соблюдение нехитрых ритуалов гарантирует райскую жизнь.
Может быть в данном споре как раз и столкнулись две несовместимые системы мышления: вера, против разума или гуманитарий против технаря.
Поэтому призываю собратьев беречь свои нервы, а если кто-то озабочен деструктивным влиянием статьи на неокрепшие умы, то для того и создан рейтинг публикаций.
(73) Артано,
Очередной пост не по теме, ниочем.
Как минимум: крайне странный отказ от аппаратных RAID контроллеров, есть, конечно, условия, при которых это оправдано, всегда экономия, но заменить его SATA дисками не получиться, даже SSD. mdadm, со всем уважением к нему, это не тоже самое, как хороший аппаратный контроллер с оптимизацией команд и кешированием (не путайте с дешевыми HBA). Куча вариантов СХД, но нормального (бесплатного) кеширования для mdadm нет до сих пор, к слову говоря если SSD диски не серверные — то быстро трешатся, как показывает практика примерно раз в год/полтора, почитайте статью на хабре от iHor, если не ошибаюсь. В аппартных контроллерах свой процессор, обьемный кеш, оптимизация команд! и ssd кеш из коробки. Уже молчу про SAS интерфейс, он то же другой, несмотря на внешнюю схожесть.
(75)Современные SSD обеспечивают очень хорошую скорость и надежность, даже не серверные, проверено практикой. Одно дело статья, другое дело своими руками. Собранный сервер, по топовому варианту этой статьи, безотказно работает более 3-х лет. Здоровье SSD накопителей в норме.
(76) Молодец. и это означает, что у вас нет особых нагрузок на дисковую подсистему, как у нас, серверные не просто так стоят дороже и RAID спасает c кешем на SSD.
Сколько времени займет восстановление данных при сбое накопителя в середине рабочего дня? Что будет если часть данных запишется с ошибками и попадет в бекап?
(77)
Нагрузка довольно серьезная, PG много данных пишет в свои кэши, а потом и в базы. 1С УТ расслабится накопителям не дает.
(77)
Серверные SQL пишут организуя очереди данных для записи. Если база файловая, тогда конечно интеллектуальный RAID необходим.
(77)
На этот случай резервный сервер, данные за день пропадут. Восстановление из бэкапа около часа. На случай критичного отношения к простоям есть варианты кластеров 1С.
(77)
Будет большая проблема, но как с этим бороться совершенно непонятно. Успокаивает только одно, что если это системная ошибка скорее всего механизмы 1С будут вываливать ошибку.