gifts2017

Особенности работы сервера 1С: Предприятия и PostgreSQL для Windows, повышение быстродействия системы

Опубликовал Евгений Бочкарев (Ликреонский) в раздел Администрирование - Системное

Опыт эксплуатации системы 1С: Предприятие 8.3 на основе сервера 1С и PostgreSQL под Windows.
Конфигурации 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 ГГц.

    

 

См. также

PowerTools от 1 000
Подписаться Добавить вознаграждение

Комментарии

1. Caponid V (caponid) 02.07.16 10:43
хм.. а где собственно особенности - кроме как работа на "псевдо серверном железе с псевдо серверной операционкой"?
Название статьи можно менять на другое - Как в попытках экономить (не относится к PostgresSQL) мы имеем проблемы с производительностью.
VampirRo; Diego_Iv; plmshka; dabu-dabu; oleg21592; tigory; +6 1 Ответить 1
2. Евгений Бочкарев (Ликреонский) 02.07.16 17:18
(1) caponid,
Название статьи можно менять на другое

Правильно, Достоевский пусть поменяет название "Преступление и наказание" на "Пособие по убийству старушек", а "Идиот" заменит на название "Комментатор на Инфорстарте".
Если при прочтении у Вас возникли мысли (удачный вариант), это необязательно мысли автора статьи. Вы увидели, то что увидели. Это Ваши мысли, напишите статью и тогда расскажите свои.
3. Dim Dragonim (Dragonim) 06.07.16 09:15
Небольшая поправка: На отдельный жёсткий диск надо выносить журнал транзакций PostgreSQL.

Теперь немного по статье:
1. Картинки, сканы документов и прочее в этом роде необходимо хранить на отдельном, можно медленном, диске, а не увеличивать базу данных. Для хранения файлов отдельно в УТ 11 встроен специальный инструмент.
2. Судя по вашей итоговой картине у вас нет зеркалирования дисков и про бекапы вы ни чего не сказали. Итог будет очень плачевен.
3. "Дал всем пользователям права на чтение всех документов", дали бы сразу административные права всем, зачем париться с правами доступа *поднял табличку "сарказм"*
h00k; VampirRo; kostyag; Diego_Iv; Ali1976; dabu-dabu; oleg21592; +7 Ответить 2
4. Иван (mythos) 06.07.16 09:23
Apache Web сервер на Windows не показал высокого быстродействия. IIS web сервер показал более высокое быстродействие.
Какими средствами измеряли быстродействие? Вопрос не праздный, на нашем сервере стоит апач в связке с 1С мини и постгрес, пользователи работают через веб не в локалке в тонких клиентах, правда пользователей всего 5, может на таком количестве особой нагрузки не почувствуешь...

Решили обновить УТ 11.1 на УТ 11.2. Свертку данных решили не делать, "нельзя" удалять ценные статистические данные, которые необходимы при планировании закупок и продаж. Обновлять без свертки - это крупная ошибка! Учет мы вели немного нестандартно.
Тоже есть в планах обновление, свёртка не рассматривается в принципе. На какие грабли наступили при обновлении? У нас база 35Гб, резервная копия делается средствами постгре, сколько выгрузка средствами 1с весит не пробовали выяснять... Закрытие месяца делается несколько часов.
5. Евгений Бочкарев (Ликреонский) 06.07.16 09:26
(3) Dragonim,
Картинки, сканы документов и прочее в этом роде необходимо хранить на отдельном, можно медленном, диске, а не увеличивать базу данных.

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

Ясное дело резервное копирование выполняется. Делается средствами 1С. Мне понравилась поговорка: администраторы делятся на две категории: те кто делает бэкап и тех кто скоро будет делать бэкап.
6. Евгений Бочкарев (Ликреонский) 06.07.16 09:35
(4) mythos,
Какими средствами измеряли быстродействие?

Монитор ресурсов Windows. Суть в том, что при наличии севера 1С Предприятие Web сервер не играет столь важной роли в обработке данных. Иначе в варианте когда Web сервер обрабатывает запросы к базе данных.
На какие грабли наступили при обновлении?

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

База PG 18 Гб, выгрузка .dt 7 Гб. В моем варианте, средствами PG очень долго делается и может закончится ошибкой.
7. Евгений Бочкарев (Ликреонский) 06.07.16 09:38
(4) mythos,
Закрытие месяца делается несколько часов

В моей конфигурации минут за 5 1 месяц закрывается. Ситуация такая, что задним числом регулярно правят документы и закрывать месяца (2-5 обычно) приходится по несколько раз в день.
8. Евгений Бочкарев (Ликреонский) 06.07.16 09:42
(3) Dragonim,
у вас нет зеркалирования дисков

Несомненно это большая проблема, уровень отказоустойчивости низкий. RAID не используем намеренно.
Отказоустойчивость отдельная тема. Очень дорогостоящая и сложная. Пока проще заменить оборудование полностью, чем резервировать.
Мы надеемся в случае выхода из строя сервера, восстановить из резерва. Проводили "тренировки", час другой простоя сервера, только внесет свежую струю в коллектив.
9. Dim Dragonim (Dragonim) 06.07.16 14:49
В зависимости от поставленной задачи гут быть разные варианты. Сложно утверждать, когда не ясна полная картина.

Реляционные базы данных не предназначены для хранения бинарных данных. От того что они это могут делать, не значит что это стоит делать. Лучше замедлить доступ к файлам чем замедлить всю базу данных и увеличить её объём.

Ясное дело резервное копирование выполняется. Делается средствами 1С.

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

Несомненно это большая проблема, уровень отказоустойчивости низкий. RAID не используем намеренно.

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

Проводили "тренировки", час другой простоя сервера, только внесет свежую струю в коллектив.

"Поставить новый сервер, установить и настроить его, подключить к системе" за 1 час???? Я бы на это посмотрел.
10. Евгений Бочкарев (Ликреонский) 06.07.16 15:33
(9) Dragonim,
В вашем случае необходимо делать резервные копии средствами базы данных.;

Пробовал, делается неприемлемо долго. И восстанавливается через раз.
Выгрузка баз в dt файл не считается резервированием.

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

Иногда RAID глючит, последствия ужасны, если контроллер принимает решение восстановить копию с убитого накопителя. Я с этим несколько раз сталкивался.
Залог быстрого восстановления сервера (1-2 часа) - это SSD накопители и резервное копирование всех носителей системы.
WellMaster; bobyor; +2 Ответить 2
11. Антон Стеклов (asved.ru) 06.07.16 16:02
Нет, ну а в чем особенности-то?

про табличные блокировки в файловой базе вы не знаете
про режимы wal вы не знаете
про искоробочную репликацию PG вы не знаете
про распухание таблиц вы не знаете
про специфику RLS и порядок ее анализа на pg вы не знаете

По сути вы распараллеливаете нагрузки на IO по разным шпинделям, не зная о том, что нормально функционирующий сервер СУБД не задерживает выполнение запросов на IO.
12. Кирилл Бондаренко (karapuzzzz) 06.07.16 16:16
Настройки Postgres делали? Можно conf в студию? Желательно, прикрепить к статье. На стоковых настройках Postgres не то чтобы "лагает", но очень не оптимально работает.
Не ясен режим блокировок, который выставлен в конфигурациях. Postgres это не блокировочная СУБД и настройки блокировок в 1С должны быть соответствующие.

Если это не указать, то я могу сказать, что у Вас полностью не настроенная система и все Ваши SSD абсолютно бестолковая трата денег.

P.S.: Не надо RLS - отключите RLS.
plmshka; BigB; +2 Ответить 1
13. Евгений Бочкарев (Ликреонский) 06.07.16 16:20
(11) asved.ru,
Статья написана для широкого круга лиц популярным языком и без заморочек. Цель доступно объяснить и сразу применить в жизни.
14. Евгений Бочкарев (Ликреонский) 06.07.16 16:30
(12) karapuzzzz,
Postgres это не блокировочная СУБД и настройки блокировок в 1С должны быть соответствующие.

Блокировки не изменял, что стоит от производителя конфигурации, то и осталось.
Conf почти без изменений, что могу вспомнить: shared_buffers = 512MB # min 128kB. После этого стали живее исполняться большие запросы.
Может чего еще менял, но не думаю что это оказало сильное влияние на работу.
Версия PG 9.4.2-1.1C
15. Антон Стеклов (asved.ru) 06.07.16 16:50
(13) Ликреонский, вообще - на здоровье, к таким как я больше заказчиков придет :)
16. Евгений Бочкарев (Ликреонский) 06.07.16 16:53
(15) asved.ru,
Заказчики любят объяснения попроще, а иначе просто непонятно.
Если я буду заказчиком, то обращусь к Вам за советом.
17. Антон Стеклов (asved.ru) 06.07.16 17:02
(16) Ликреонский, заказчик платит не за объяснения, а за качественно работающую информационную систему. Соответственно нужда в объяснениях отпадает. Ну или за отдельную плату без гарантии понятности неспециалисту, но на моей памяти никто такого не хотел.
18. Евгений Бочкарев (Ликреонский) 06.07.16 17:12
(17) asved.ru,
Перед созданием системы нужно объяснить, что получится и как это работает. Главное не перебрать с терминологией. Если на лбу заказчика появляются складки головной боли, то скорее всего он уже не заказчик.
Нужда в объяснениях есть всегда. Просто так деньги никто не отдает, как минимум хотят аргументы в пользу системы. У нас рыночные отношения и у заказчика есть выбор: работать с тем занудой или с тем общительным, толковым парнем.
Поэтому на мой взгляд менеджеры по продажам не должны обладать излишними знаниями, они им только вредят, но в тоже время в вопросах разбираться нужно.
При написании статей нужно учитывать, что основная масса читателей специалисты в других областях и слишком много подробностей усыпят их внимание.
Как по мне нужно статьи чтоб было написано: быстро, четко, действенно (и картинок побольше). Остальное можно причитать в технической документации к программному продукту.
19. Антон Стеклов (asved.ru) 06.07.16 17:21
20. Михаил Краснобаев (milo1) 07.07.16 09:56
(10) Ликреонский,

Иногда RAID глючит, последствия ужасны, если контроллер принимает решение восстановить копию с убитого накопителя.


Это как? Контроллер решений не принимает.

21. Евгений Бочкарев (Ликреонский) 07.07.16 10:07
(20) milo1,
Контроллер решений не принимает.

Хм, а кто принимает в RAID решение о том какая копия данных актуальна?
Например, в RAID на одном из накопителей обнуляется FAT. Запись определяется как более новая, на остальные накопители транслируется информация о изменениях. Результат: данные недоступны.
22. Иван (mythos) 07.07.16 13:29
(11) asved.ru,

порекомендуйте, пожалуйста, литературу или ресурсы откуда можно почерпнуть всю эту информацию.
Ликреонский; +1 Ответить 1
23. alexey klimkin (alexlights) 07.07.16 16:23
В настоящий момент 25 пользователей, сервер работает с большим запасом быстродействия. База данных торговли PostgreSQL имеет размер 18 Гб, .dt базы 7 Гб. Сервер имеет на борту 32 ГБ ОЗУ, процессор I7 4770 3.4 ГГц.

Вот не увидел экономии. Такие мощности использовать под две базы, которые еще и размером небольшие? У меня сейчас такие мощности на тестовом сервере, на котором крутится около 10 баз разработчиков конфигурации УПП 1.3, каждая 300 гб размером. Все летает, причем без использования SSD дисков для баз данных.
Ну и о самой статье: Автор не знает, как работает платформа 1С, но героически лечит геморрой через гланды.
24. Евгений Бочкарев (Ликреонский) 07.07.16 16:46
(23) alexlights,
У меня сейчас такие мощности на тестовом сервере, на котором крутится около 10 баз разработчиков конфигурации УПП 1.3, каждая 300 гб размером. Все летает, причем без использования SSD дисков для баз данных.

Сколько пользователей одновременно работает? Судя по тому что тест, по одному пользователю работают. Не в рабочем режиме, а только тест. Конечно все летает. УПП 1.3 сравнивать некорректно, УТ 11.2 удивила прожорливостью пространства, даже по сравнению с 11.1. При проведении в 11.2 используется большое количество запросов и обработка данных.
25. Adapter Бахтыреев (adapter) 07.07.16 16:59
больше похоже на антирекламу. Из серии "как делать не надо". Или за что мы все таки платим в серверных решениях
Артано; Diego_Iv; 1С_Мастер; +3 1 Ответить 1
26. alexey klimkin (alexlights) 07.07.16 17:20
(24) Ликреонский,
Я уже заметил по ответам, что любое мнение, которые не соответствует мировоззрению автора жестко им минусуется, прям комплексы какие - то. Есть два мнения, автора и неправильное :)

Сколько пользователей одновременно работает? Судя по тому что тест, по одному пользователю работают

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

УТ 11.2 удивила прожорливостью пространства

Знали бы архитектуру 1С, RLS, настройки темповых баз - Вас бы ничего не удивляло.

Вкратце: Статья - советы, как делать не надо.
Артано; JohnyDeath; +2 1 Ответить 2
27. Евгений Бочкарев (Ликреонский) 07.07.16 17:48
(26) alexlights,
Я уже заметил по ответам, что любое мнение, которые не соответствует мировоззрению автора жестко им минусуется, прям комплексы какие - то. Есть два мнения, автора и неправильное :)

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

Пользователи только тестированием и занимаются? 10 баз по 50 пользователе = 500, явно не соответствует действительности.
28. Евгений Бочкарев (Ликреонский) 07.07.16 17:50
(25) adapter,
больше похоже на антирекламу. Из серии "как делать не надо".

Пост больше похож на троллинг лишь бы привлечь к себе внимание.
29. Евгений Бочкарев (Ликреонский) 07.07.16 17:52
(26) alexlights,
больше похоже на антирекламу. Из серии "как делать не надо".

Не соответствует действительности. Советы в конце статьи, видимо до конца Вы не дочитали. В статье перечислены ошибки, которые легко совершить.
Минуса за посты Вами заслужены.
30. alexey klimkin (alexlights) 07.07.16 18:20
Коллеги, надо поднять рейтинг статьи. Благодаря таким неучам, у нас есть работа :) Пусть больше человек внемлет советам мегаспециалиста дантиста - проктолога.
denmax; plmshka; +2 1 Ответить 1
31. Евгений Бочкарев (Ликреонский) 07.07.16 19:29
(30) alexlights,
И это говорит человек не написавший НИЧЕГО, кроме бессмысленного комментария.
32. Василий Тёркин (1С_Мастер) 08.07.16 09:23
Бгг, клиент-серверная база масштабируется лучше файловой, а постгри для лучшей производительности надо настраивать. Прямо открытие Америки
Рассуждения насчет падающего рэйда так вообще заставляют хохотать в голос. Спасибо, повеселили
Ну и напоследок совершенно непонятно почему был куплен х64 сервер при том, что намного эффективнее было бы купить сервер х32, а разницу вложить в железо. Да хоть в ту же оперативку.
Артано; +1 1 Ответить 2
33. Евгений Бочкарев (Ликреонский) 08.07.16 09:35
(32) 1С_Мастер,
был куплен х64 сервер при том, что намного эффективнее было бы купить сервер х32, а разницу вложить в железо. Да хоть в ту же оперативку.

х32 больше 4 ГБ ОЗУ не использует, какой смысл вложиться в оперативку? Необдуманный вредный совет, минус к карме.
34. Евгений Бочкарев (Ликреонский) 08.07.16 09:39
(32) 1С_Мастер,
Рассуждения насчет падающего рэйда так вообще заставляют хохотать в голос. Спасибо, повеселили

Пожалуйста. Весело это когда из RAID пропадает вся информация. Если не сталкивались, от этого веселитесь, когда случится, не весело будет.
Это не рассуждения - это опыт.
35. Василий Тёркин (1С_Мастер) 08.07.16 09:48
(33) Ликреонский,
х32 больше 4 ГБ ОЗУ не использует, какой смысл вложиться в оперативку? Необдуманный вредный совет, минус к карме.


А вы анализировали сколько оперативки у вас на данный момент потребляет один рабочий процесс сервера предприятия? Если он у вас вдруг вдруг сожрал больше четырех гигабайт памяти, я бы посоветовал поменять настройки, чтобы добавилось еще несколько процессов. Ограничение по оперативке идет именно на один рабочий процесс, а одному рабочему процессу четырех гигабайт за глаза. Как писал Гилёв (Возможно я ошибаюсь и это писал не он, пруф искать лениво), разница в производительности между х64 и х32 версиях сервера будет заметна только на действительно больших базах (ваша же сейчас меньше 20ГБ и большую ее часть составляют картинки) и будет в пределах 5-10%

"Зачем же много оперативки?" спросите вы. А для постгреса, он ее очень любит и любит кэшировать таблицы в оперативной памяти. Чем больше свободной памяти вы ему дадите, тем больше возможностей для кэширования, тем быстрее исполняются запросы.

PS. Вы очень любите плеваться минусами в карму, не надо так. Если вы плюнете в комментаторов, комментаторы утрутся. Если комментаторы дружно плюнут в вас, вы утонете.
Артано; VampirRo; adapter; +3 Ответить 1
36. Василий Тёркин (1С_Мастер) 08.07.16 09:56
Пожалуйста. Весело это когда из RAID пропадает вся информация. Если не сталкивались, от этого веселитесь, когда случится, не весело будет.
Это не рассуждения - это опыт.

Статистика беспощадна. Проблемы с жесткими дисками происходят куда чаще, чем с рэйд контроллерами, а наличие рэйда не избавляет вас от обязанности делать бэкапы. Но если вы так уж не доверяете аппаратному рэйду, есть программный. Точных данных у меня нет, но вызывающее доверие админы говорили о его исключительной надежности.
37. Евгений Бочкарев (Ликреонский) 08.07.16 10:04
(35) 1С_Мастер,
Вы очень любите плеваться минусами в карму, не надо так.

Я также охотно ставлю плюсы.
Отвечу на некоторые Ваши вопросы:
1. База уже немного больше 21 Гб.
2. Сервер 1С предприятия играет не последнюю роль и о его производительности тоже нужно заботиться. В данный момент он потребляет 3.3 Гб ОЗУ (перезапуск был 02:00 сегодня, утро пятница, пользователи вялые). Иногда, при больших нагрузках он 10 Гб ОЗУ употребить может. Если долго не перезапускать, то постепенно много памяти под себя закэширует (от настроек зависит). Я по ночам перезапускаю сервер 1С Предприятие (не целиком компьютер), так надежнее работает.
3. Выборка на сервере идет в основном из памяти, это несомненно ускоряет работу. На последнем скриншоте в статье снимок монитора ресурсов, там видно, что не найденных в памяти страниц около 20%.
38. WellMaster (WellMaster) 08.07.16 10:06
(33) Ликреонский,
Вы меня простите, конечно, но про рабочие процессы вы в курсе?
39. Евгений Бочкарев (Ликреонский) 08.07.16 10:07
(36) 1С_Мастер,
У меня не стоит задача абсолютно бесперебойной работы, с горячей заменой деталей сервера. Перерыв в несколько часов неприятен, но не критичен.
При другой задаче, я бы рассмотрел и другие варианты решения. И не только RAID, но и репликации.
40. Евгений Бочкарев (Ликреонский) 08.07.16 10:08
(38) WellMaster,
Вы меня простите, конечно, но про рабочие процессы вы в курсе?

Бог простит.
За мое образование не Вам стоит беспокоится.
41. Василий Тёркин (1С_Мастер) 08.07.16 10:13
1. База уже немного больше 21 Гб.

Выдерните из нее таки картинки, не дело их хранить в базе

Сервер 1С предприятия играет не последнюю роль и о его производительности тоже нужно заботиться. В данный момент он потребляет 3.3 Гб ОЗУ (перезапуск был 02:00 сегодня, утро пятница, пользователи вялые). Иногда, при больших нагрузках он 10 Гб ОЗУ употребить может. Если долго не перезапускать, то постепенно много памяти под себя закэширует (от настроек зависит). Я по ночам перезапускаю сервер 1С Предприятие (не целиком компьютер), так надежнее работает.

Рабочие процессы же. У меня сейчас семь рабочих процессов сожрали совместно 12 ГБ озу. На х32 сервере. На х64 они потребили бы примерно столько же. А разница в стоимости лицензии двукратная

У меня не стоит задача абсолютно бесперебойной работы, с горячей заменой деталей сервера.

Если диск сдохнет у вас в конце дня, а бэкап делался ночью, придется как-то восстанавливать всю работу за день. Не смертельно, но приятного мало
42. Евгений Бочкарев (Ликреонский) 08.07.16 10:26
(41) 1С_Мастер,
Если диск сдохнет у вас в конце дня, а бэкап делался ночью, придется как-то восстанавливать всю работу за день. Не смертельно, но приятного мало

Это приемлемый ущерб, к нему готовы.
Выдерните из нее таки картинки, не дело их хранить в базе

Зря советуете не зная всех деталей.
Вернемся к х32-х64:
Сервер 1С Предприятие х64 умеет занимать ресурсы процессора более одного ядра. Когда ему надо он берет много ресурсов и быстро работает.
х32 занимает ресурсов не более ядра.
Например: я запускаю какой нибудь невероятный отчет на восьми-ядерном сервере. На сервере х64 будет на этот процесс будет выделено 40%, при х32 на процесс выделится 12,5%. Разница в скорости формирования отчета будет соответственная.
43. Василий Тёркин (1С_Мастер) 08.07.16 10:44
Например: я запускаю какой нибудь невероятный отчет на восьми-ядерном сервере. На сервере х64 будет на этот процесс будет выделено 40%, при х32 на процесс выделится 12,5%. Разница в скорости формирования отчета будет соответственная.

Ключевое слово тут "Невероятный". Даже если этот отчет тянет данные из всех таблиц базы за весь период ее существования основная нагрузка ляжет на БД, на постгрес. Если отчет написан разумно, без каких-то безумных вычислений на стороне сервера предприятия.
Я не спорю о том, что х64 сервер производительней. Конечно, он производительней. Но разницу в производительности вы заметите когда база у вас перевалит за сютню гигов. (В вашем случае за 5 сотен ибо ситуация когда бэкап базы весит едва ли не в половину от самой базы ненормальна)
44. Евгений Бочкарев (Ликреонский) 08.07.16 10:49
(43) 1С_Мастер,
Но разницу в производительности вы заметите когда база у вас перевалит за сютню гигов.

Не в размере дело. Объединения таблиц, выборка за большой период, регистры в миллионы записей нагрузят и сервер 1С Предприятие и PG.
В вашем случае за 5 сотен ибо ситуация когда бэкап базы весит едва ли не в половину от самой базы ненормальна

Любопытно, обоснуйте пожалуйста это утверждение.
"-","+"
45. Василий Тёркин (1С_Мастер) 08.07.16 11:33
Любопытно, обоснуйте пожалуйста это утверждение.

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

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

Объединением таблиц занимается СУБД, как и выборкой. Сервер предприятия же, если упрощенно, строит план запроса, отдает субд, принимает и обрабатывает результат. Конечно, результат тоже может содержать многие миллионы строк и на их вывод в табличный документ потребуются долгие часы. Но кому, простите, понадобится отчет из многих миллионов строк? Кто эти миллионы строк будет изучать и анализировать? И чем тут поможет та самая многопоточность? Вывод результата выборки в отчет все равно будет идти в одном потоке
46. Василий Тёркин (1С_Мастер) 08.07.16 11:44
Чтобы быть полностью объективным, хочу добавить что мои рассуждения о связи х64 сервера и объеме базы достаточно поверхностные. Первостепенен тут не скорее не объем базы, а количество одновременно пользователей и их активность, но обычно с большими базами работает много пользователей, а с маленькими мало, поэтому я говорю именно с точки зрения объема, чтобы не усложнять дискуссию лишними подробностями.
Ликреонский; +1 Ответить
47. Евгений Бочкарев (Ликреонский) 08.07.16 11:49
(45) 1С_Мастер,
Бэкап це по сути архив с базой. Данные из таблиц обычно сжимаются очень хорошо, картинки и видео сжимаются очень плохо.

Про сжатие никто не говорил. .dt не содержит индексы и избыточное пространство таблиц, поэтому меньше базы PG.
бэкап будет весить в десятки раз меньше, около 2-3% от объема самой базы.

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

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

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

Не на столько их там много.
48. Василий Тёркин (1С_Мастер) 08.07.16 11:59
Про сжатие никто не говорил. .dt не содержит индексы и избыточное пространство таблиц, поэтому меньше базы PG.

Попробуйте сжать dt архиватором. Увидите, что не очень-то и сжимается. И да, бэкап с помощью dt це моветон. Не спорю, он удобен, но dt не предназначен для бэкапа, делайте бэкапы с помощью субд.


Чаще нужно обработать миллионы строк и вывести несколько.

Разумный разработчик предоставит обработку миллионов строк СУБД

Не на столько из там много.

Вывод о большом количестве картинок я сделал исключительно из вашей информации о размерах бэкапов, которые могут быть настолько большими именно по причине большого количества плохо сжимаемых данных
49. Евгений Бочкарев (Ликреонский) 08.07.16 12:02
(48) 1С_Мастер,
Не спорю, он удобен, но dt не предназначен для бэкапа, делайте бэкапы с помощью субд.

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

Вывод неверен. dt как Вы сами и сказали не сжимается.
Разумный разработчик предоставит обработку миллионов строк СУБД

Кому нужен такой разум?
50. Василий Тёркин (1С_Мастер) 08.07.16 13:09
Этот баян про .dt очень распространился.

Это не баян, это тот самый опыт

Вывод неверен. dt как Вы сами и сказали не сжимается.

А почему не сжимается? Да потому, что уже сжат. И если 20 гигов по сути текстовых и числовых данных не могут ужаться до 200 Мб, есть там что-то еще кроме текста и чисел. Что же это?


Кому нужен такой разум?

Ну, работодателям обычно нужны специалисты способные решить задачу оптимальным способом, а не тем, который требует перебора миллионов строк.
51. Евгений Бочкарев (Ликреонский) 08.07.16 13:16
(50) 1С_Мастер,
Ну, работодателям обычно нужны специалисты способные решить задачу оптимальным способом, а не тем, который требует перебора миллионов строк.

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

У меня опыт о .dt только положительный. Восстанавливается почти гарантировано, довольно быстро, переиндексируется при загрузке. Компактное хранение данных. Нельзя выгрузить не в монопольном режиме (это спорно, но надежнее и спокойнее). Периодически проверяю распаковывается ли бэкап, разворачиваю в базу разработки свежие бэкапы. Пока сбоев не было. Скорость выгрузки выше, чем скорость выгрузки из PGAdmin III.
Какой Ваш опыт?
52. Василий Тёркин (1С_Мастер) 08.07.16 13:27
Скорее наоборот. Базы содержат данные о важных частях работы организации и ничего работодатель из этого ни потерять, ни пропустить не хочет.

Вот признайтесь, вы меня троллите?

Какой Ваш опыт?

В дополнение к бэкапам средствами СУБД я делаю дампы в dt, т.к. это действительно удобно, отрицать описанные вами преимущества я не буду. Если надо развернуть базу из копии первым делом разворачиваю из дт. Получается не всегда, достаточно часто вылезают проблемы с уникальными индексами. Точную статистику не веду, ни к чему она мне.
Очень часто подобные проблемы случаются при переводе в клиент-серверный вариант файловых баз (тут много зависит от возраста базы, чем база старше, тем выше вероятность чего-то нехорошего). Да и тут, на инфостарте очень много похожих случаев описано, почитайте хотя бы вот это http://infostart.ru/public/285883/
53. Евгений Бочкарев (Ликреонский) 08.07.16 13:37
(52) 1С_Мастер,
Вот признайтесь, вы меня троллите?

Я думаю что это вы троллите. Много $m за посты в этой начислили?
Очень часто подобные проблемы случаются при переводе в клиент-серверный вариант файловых баз (тут много зависит от возраста базы, чем база старше, тем выше вероятность чего-то нехорошего)

У меня есть такая база, .dt из нее не делаются, тогда средствами SQL ее таскать приходиться. Но она не очень большая и PGAdmin реально дождаться.
С рабочей базой проблем нет, .dt отлично выгружаются и загружаются.
54. Василий Тёркин (1С_Мастер) 08.07.16 13:48
Я думаю что это вы троллите. Много $m за посты в этой начислили?

Какие-то крохи, 1 или 2 sm. И да, я искренне стараюсь не сорваться с простого сарказама на троллинг

С рабочей базой проблем нет, .dt отлично выгружаются и загружаются.

Будет обидно, если дамп из dt откажется загружаться как раз в тот день, когда навернется жесткий диск
Ликреонский; +1 Ответить 1
55. Евгений Бочкарев (Ликреонский) 08.07.16 13:54
(54) 1С_Мастер,
Какие-то крохи, 1 или 2 sm.

Статьи писать немного выгоднее :).
И да, я искренне стараюсь не сорваться с простого сарказама на троллинг

За это плюс от меня лично.
56. Антон Стеклов (asved.ru) 08.07.16 21:20
Вернемся к х32-х64:
Сервер 1С Предприятие х64 умеет занимать ресурсы процессора более одного ядра. Когда ему надо он берет много ресурсов и быстро работает.
х32 занимает ресурсов не более ядра.
Например: я запускаю какой нибудь невероятный отчет на восьми-ядерном сервере. На сервере х64 будет на этот процесс будет выделено 40%, при х32 на процесс выделится 12,5%. Разница в скорости формирования отчета будет соответственная.


Бред. Даже не буду пояснять, почему. Учите матчасть.

Решение о сервере x64 действительно правильное, но исключительно в силу ограничения x86 процесса по памяти. Частенько бывают ситуации, когда файловая БД или сервер x86 не могут прожевать достаточно большой набор управляемых блокировок, падают по недостатку памяти. Наиболее частый пример - замена значений средствами БСП.

Этот баян про .dt очень распространился.

Это не баян, а официальная документация 1С. Которую Вы поленились прочитать.
Артано; A_Max; cleaner_it; 1С_Мастер; +4 1 Ответить 2
57. Антон Стеклов (asved.ru) 08.07.16 21:38
По поводу размера pgdump 1С_Мастер скорее всего прав.

[root@zmon pg]# cd /var/adm/pgdb/data/
[root@zmon data]# du -sh base
5,0G    base
[root@zmon data]# cd /var/backup/pg/
[root@zmon pg]# du -sh ./zabbix_201607080347.pgdump
522M    ./zabbix_201607080347.pgdump
[root@zmon pg]#
...Показать Скрыть

Это база, состоящая в основном из коротких числовых значений.

С другой стороны лиц, заявляющих о прямой связи размера базы с ее быстродействием, нужно гнать из профессии ссаными тряпками.
58. Антон Стеклов (asved.ru) 08.07.16 21:43
(22) mythos, начните с сайтов postgrespro и postgresql.leopard.in.ua
59. Антон Стеклов (asved.ru) 08.07.16 21:49
(27)
Минус я поставил

(29)
Минуса за посты

(37)
ставлю плюсы

(44)
"-","+"

(55)
За это плюс


Ну ты понел
60. Евгений Бочкарев (Ликреонский) 09.07.16 17:49
(56) asved.ru,
Это не баян, а официальная документация 1С. Которую Вы поленились прочитать.

Обозначая dt не как резервное копирование, 1С снимает с себя ответственность на случай потере данных. А иначе по судам затаскают.
61. Евгений Бочкарев (Ликреонский) 09.07.16 18:42
(56) asved.ru,
Бред. Даже не буду пояснять, почему. Учите матчасть.

Все так говорят, когда аргументов нет, а сказать очень хочется. Я думаю Вы либо пьяны, либо обижены. Ну, и без минуса от меня, Вам никак не обойтись
62. Pavel Fomin (Pasha1st) 10.07.16 22:12
(51) Ликреонский,
У меня опыт о .dt только положительный. Восстанавливается почти гарантировано, довольно быстро, переиндексируется при загрузке. Компактное хранение данных. Нельзя выгрузить не в монопольном режиме (это спорно, но надежнее и спокойнее). Периодически проверяю распаковывается ли бэкап, разворачиваю в базу разработки свежие бэкапы. Пока сбоев не было. Скорость выгрузки выше, чем скорость выгрузки из PGAdmin III.

Можно только ещё раз посоветовать разобраться с настройками PG и системы целиком.
Я последние два года периодически занимаюсь восстановлением баз 1С, плюс администрирование, и мой опыт как раз говорит что .dt - не лучший вариант.
"Восстанавливается почти гарантированно" - полно случаев когда играет именно это "почти". Самое частое - проблема с неуникальными значениями при переносе из файлового варианта в MS/PG SQL, но не только.
Сразу уточню, я предпочитаю pg_dump в .sql.bz2 (через lbzip2 на linux'е) - и поправить можно при необходимости, и diff можно делать, и сжимать можно. На скорость никогда не жаловался. В первый раз слышу чтобы дамп мог не сняться - у нас используется в PG база на 20+Гб без сохранения двоичных данных.
"Довольно быстро" - восстановление средствами pg на моем опыте было быстрее чем из .dt
Необходимость монопольного режима я воспринимаю скорее как минус
Реиндексация проходит аналогично

Да, проверку разворачиваемости бекапов делать надо вне зависимости от способа создания бекапа, но сбоев больше было с .DT
Ликреонский; +1 Ответить
63. Kostya G (kostyag) 17.07.16 14:27
(10) Ликреонский,
Иногда RAID глючит, последствия ужасны, если контроллер принимает решение восстановить копию с убитого накопителя.

Я что-то с трудом вспоминаю, как контроллер может "принять решение восстановить копию", при том условии что у них понятия "копии" отсутствует.
Если конечно использовать дешевые софт-контроллеры, и встроенные в ОС средства, то такие результаты возможны, но опыт показывает это кривые руки или не знание элементарной матчасти.
Ну и используйте железные рейд-контроллеры, это лучше и дешевле одного дня работы фирмы.

Опыт интересный, так как занимаюсь щас внедрением УТ11.2, но такую схему очканул бы делать.:)
64. Евгений Бочкарев (Ликреонский) 18.07.16 08:52
(63) kostyag,
Если конечно использовать дешевые софт-контроллеры, и встроенные в ОС средства, то такие результаты возможны, но опыт показывает это кривые руки или не знание элементарной матчасти.

Мой отрицательный опыт именно на аппаратных контроллерах.
Странно, но комментарии есть прямо противоположные. Кто говорит о софт RAID и рекомендует использовать их, а кто о аппаратных. Видимо сказывается недостаточный опыт оппонентов в использовании оборудования.
Опыт интересный, так как занимаюсь щас внедрением УТ11.2, но такую схему очканул бы делать.:)

Какую схему планируете использовать?
65. борян петров (TODD22) 18.07.16 08:59
(49) Ликреонский,
Этот баян про .dt очень распространился.

Баян это комментарии типа: "у меня .dt всегда загружался и проблем не было". А у вас сколько баз на обслуживании?
У меня больше 200. И ситуация когда из dt база не загружается стабильно бывает 1-3 раза в квартал. Что не так уж и мало....
И читайте документацию 1С в которой всё это описано.
66. Александр Корнев (VampirRo) 19.07.16 07:48
(49) Ликреонский, У меня .dt обычно занимает до 10 процентов от объема бд. На любых базах, торговля, БГУ, ЗУП- но эти обычно не очень большие. Резервирование посредством выгрузки .dt имеет место быть но в основном на файловых базах, да и использование обычных архиваторов в этом случае намного предпочтительнее.
67. борян петров (TODD22) 19.07.16 08:36
(66) VampirRo,
Резервирование посредством выгрузки .dt имеет место быть но в основном на файловых базах

В некоторых компаниях этот вопрос задают на собеседованиях. И после бэкапа файловой базы в dt пойдёте искать другую работу.
68. Михаил Краснобаев (milo1) 19.07.16 14:47
(21) Ликреонский,

Хм, а кто принимает в RAID решение о том какая копия данных актуальна?


Никак он не определяет. Это не его задача, если диск отвечает на команды и запросы, значит он исправен.

Запись определяется как более новая, на остальные накопители транслируется информация о изменениях. Результат: данные недоступны.


Никакая запись как более новая не определяется контроллером. Вы представления не имеете как происходит запись на диски. Тем более как работают современные контроллеры.
Если у вас там что-то где-то обнулилось (читай пришла команда на запись), значит изменения будут внесены и на другие диски. Нужна система с контролем корректности данных от "тихого" повреждения - ставьте сервер с ZFS для данных. А еще лучше все критичные данные бэкапируете в зависимости от разрешенного времени простоя.
69. Евгений Бочкарев (Ликреонский) 19.07.16 16:04
(68) milo1,
Вы представления не имеете как происходит запись на диски.

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

70. Михаил Краснобаев (milo1) 22.07.16 13:07
(69) Ликреонский,

Можно говорить все что угодно, но у меня есть опыт и весьма негативный.


Если у вас контроллеры решают какие данные новые, а какие старые - это неудивительно.
71. Евгений Бочкарев (Ликреонский) 22.07.16 15:31
(70) milo1,
Если у вас контроллеры решают какие данные новые, а какие старые - это неудивительно.

Кто у вас решает, какие данные новее?
72. Kostya G (kostyag) 27.07.16 02:59
(64) Ликреонский,
Какую схему планируете использовать?

Я бы изначально использовал RAID10. :) Или хотя бы RAID1.

Мой отрицательный опыт именно на аппаратных контроллерах.
Странно, но комментарии есть прямо противоположные. Кто говорит о софт RAID и рекомендует использовать их, а кто о аппаратных. Видимо сказывается недостаточный опыт оппонентов в использовании оборудования.

Не все контроллеры, конечно, одинаково полезны. Но большинство проблем именно от неправильной настройки, либо действий сотрудников которые умудряются втыкать/вытыкать убитый винт, либо полностью игнорировать разваленный рейд.

Кто у вас решает, какие данные новее?

Давайте начнем с того, что ОС не видит винты как таковые, она работает с контроллером. Для неё контроллер это такой жесткий диск и ей в целом пофигу как и что там происходит. Так что если вы обновили данные в системе, то контроллер просто запишет данные на жесткие диски в соответствие с внутренними настройками.
Поэтому и контроллер ничего не решает, он просто пишет и следит за состоянием.

Я слышал про истории когда винт сыпался, а контроллер продолжал работать с ним, но такие истории остались давно позади.
73. Артано Майаров (Артано) 24.08.16 09:24
Это просто треш какой-то, а не обсуждение. Где-то на середине хотел написать что-то типа "спасибо всем, поржал", но дочитав до конца просто устал. Вообще, поведение автора, я лично оценил как троллинг, возможно потому, что я полагаю, что люди не бывают настолько неквалифицированы и у упорны в отстаивании очевидных глупостей. По крайней мере в таком узком сообществе как ИС.

Впрочем еще вчера был свидетелем подобной перебранки двух людей, когда один человек вел конструктивный диалог, а другой откровенно "тупил". В итоге закончилось так же - срачем и взаимной обидой. Хотя одного из участников я еще в начале спора предупредил, что "тролль детектед", но к концу беседы, я уже начал сомневаться. А вдруг действительно бывают такие люди которые не троллят, а действительно так считают? Ведь есть же тек, кто верят, что кусок мяса съеденный в пост приведет их в ад, а соблюдение нехитрых ритуалов гарантирует райскую жизнь.

Может быть в данном споре как раз и столкнулись две несовместимые системы мышления: вера, против разума или гуманитарий против технаря.
Поэтому призываю собратьев беречь свои нервы, а если кто-то озабочен деструктивным влиянием статьи на неокрепшие умы, то для того и создан рейтинг публикаций.
74. Евгений Бочкарев (Ликреонский) 24.08.16 10:03
(73) Артано,
Очередной пост не по теме, ниочем.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа