44
Рейтинг

7o2uYXg



  •   Регистрация: 18.05.2009 (14 лет назад)

  •   Был(а) на сайте: вчера в 17:14

Друзья
  • Вячеслав Гилёв
  • Андрей Бурмистров
  • Иван Гордынец
  • Дмитрий Малышев
Подписчики 11

Группы

IE 2012 Докладчик

IE 2016 Докладчик

Рейтинг 44

Инструкция по установке сервера 1С и PostgreSQL на CentOS Linux

Статья Системный администратор Программист Платформа 1С v8.3 Linux Бесплатно (free) Нет файла Инструменты администратора БД

В данной статье будет рассмотрена пошаговая установка СУБД PostgreSQL и сервера 1С:Предприятия (64-bit) на операционную систему CentOS Linux 7

08.10.2016    87105    7o2uYXg    15       

44

Комментарии

HighLoadУскорение работы конфигуратора 1С с большими прикладными решениями#71 14.01.22 23:53
(70)
Цитата
Ну мы же вроде взрослые люди, ERP и i5-8265U - это из разряда садомазо
Если что - это я не придумал, это из стартового поста взято, который собственно мы здесь обсуждаем.
HighLoadУскорение работы конфигуратора 1С с большими прикладными решениями#69 14.01.22 23:36
(66) а тут вы перевираете исходный смысл.
Там было написано "ваш бабушкин рецепт был актуален, пока не было дисков с шиной pci 4.0 и 5.0
на этих шинах сейчас есть диски сопоставимые со скоростью оперативки старых компьютеров".
Это совсем не то же самое, что "даже покруче памяти".

А про копирование объёма данных - можно например посмотреть с помощью статистики SMART объём записи на диск в начале и конце какой-нибудь тяжёлой операции (типа там обновления конфигурации ERP с реструктуризацией), и дальше думать: куда же столько пишется и зачем.
HighLoadУскорение работы конфигуратора 1С с большими прикладными решениями#67 14.01.22 23:32
(65) если на ноутбуке один диск "подо всё" - операционка и установленный софт не сильно спрашивают пользователя, что он там собирался писать "в рассрочку и помалу", или "сразу и много".

Ну и как бы это повежливее про intel 660p:

и
HighLoadУскорение работы конфигуратора 1С с большими прикладными решениями#64 14.01.22 23:20
(62) вы зачем-то сами себя убедили, что шина PCIe здесь будет настолько узким местом, что даже обсуждать более производительные ссд нет смысла. При 4х линиях PCIe 3.0 это почти 4 гигабайта в секунду, при работе в конфигураторе (то есть в однопользовательском режиме) и уж тем более ноутбуке с низковольтным процессором U - мягко говоря, именно в шину упереться будет непросто, узкие места будут другие. Там нагрузка будет падать сразу на ряд узлов: процессор для 1С, процессор для СУБД, память (пропускная способность, скорость и количество каналов), диск для 1С и диск для СУБД.

Ну и в случае 1С на SSD - ГОРАЗДО вероятнее упереться в скорость постоянной многопоточной записи мелкими пакетами, чем в ширину шины PCIe.
HighLoadУскорение работы конфигуратора 1С с большими прикладными решениями#63 14.01.22 23:15
(53) с результатами дисковой подсистемы на SSD ещё можно легко самообмануться, потому что тесты дисковой подсистемы обычно делают условно на "незамученном" агрегате, и даже на плохих убогих контроллерах с QLC флэш-памятью можно протестировать производительность SLC кэша. И в обзорах обычно тесты показывают именно на кэше.
А при реальной работе этот кэш может неприятно быстро закончиться, и тогда результаты теста были бы совсем другие, просто их никто не увидит. А конфигуратору при этом будет грустно и печально.
HighLoadУскорение работы конфигуратора 1С с большими прикладными решениями#47 14.01.22 21:48
(21) разрешите уточнить: а фраза "сервер совсем дрова" у вас всё ещё относится к обсуждению изначального поста с процессором i5-8265U?
HighLoadУскорение работы конфигуратора 1С с большими прикладными решениями#45 14.01.22 21:13
(18)
по пунктам:
1. интеловский процессор серии 8xxxU - ноутбучный слаботочный, рассчитан на длительную работу при малой нагрузке с малым нагревом. Видимо программисту такой купили для работы или он сам себе купил. На высокой частоте работает очень недолго, через несколько десятков секунд наступает ограничение теплового пакета и частота неприятно снижается. Для открытия конфигуратора этого обычно достаточно, для серьёзных нагрузок не годится категорически. Дальше зависит от сценария, надо считать: сколько времени программист теряет на ожидания, пока оборудование чего-то там обработает и сварит, и сколько времени он может сэкономить заменой оборудования. Иногда реально можно выяснить, что замена оборудования очень даже рациональна.

2. вариант с рамдиском на 4 гига хоть и имеет право на жизнь, но годится чисто "пережить пожар", если память впаяна и ссд тоже впаян. Долговременная работа 1С в таком режиме довольно быстро упрётся в то, что и при работе файлы temp могут создаваться большие, и загрузка-выгрузка какого-нибудь .dt требует свободное место в папке temp на весь размер обрабатываемых файлов;

3.0. обсуждать ограничения шины PCIe 3.0 и 4.0 на высокопроизводительных (хотя бы десктопных) SSD - это конечно прекрасно, но в подавляющем большинстве случаев при работе 1С/СУБД производительность дисковой подсистемы будет упираться в производительность контроллера ссд и флэш-памяти. Даже новейшие оптаны 5800X далеко не всегда и не во всех сценариях будут давать поток в хотя бы 4 гига в секунду, чтобы шина PCIe 3.0 реально выступила узким местом. Не говоря уже про десктопные самсунги формата M.2 (там ещё банальный перегрев отлично выступит дополнительным ограничителем, особенно внутри ноутбука). А вот разница между более старым (более медленным) и более новым (более быстрым) контроллером даже на шине PCIe 3.0 будет вполне себе заметна, очевидна и приятна.

Что же касается ситуации, с которой всё началось (см. "медленные действия конфигуратора") - лично я бы начал с анализа "а что же именно выступает узким местом?". И например, просто бы выяснил, что в ноутбуке воткнут плохой дешёвый ссд, который нагрузку на запись элементарно не держит (какой-нибудь позорный intel 660p). И дальше бы думал в сторону замены этого ссд или добавления вторым хотя бы небольшого ссд попроизводительней (например Samsung 970 Evo Plus гигов на 512, если есть возможность воткнуть второй M.2 или хотя бы 860 Evo, если есть только SATA), чтобы всю интенсивную дисковую нагрузку вынести туда.
И не бороться с ветряными мельницами, изобретая очередные велосипеды.
ПубликацииОбзор облаков для 1С (часть 2)#49 30.05.20 0:07
Вдогонку. Тут наблюдаю попытки демонизировать тест Гилёва, как будто этим тестом отменяется необходимость внедрения и строгого отслеживания APDEX. Это категорически не так. Тест является по сути первым шагом в борьбе за производительность системы. Если результат теста ожидаемо высокий - дальше к нему до каких-то серьёзных происшествий возвращаться повода просто не будет, теперь сосредоточимся на APDEX, мониторингу загрузки оборудования, долгих запросов, блокировок и прочего.Если же результат теста внезапно низкий - неплохо бы потратить немного времени, разобраться в причинах низкой оценки, довести её до примерно ожидаемой для данного оборудования и опционально применяемой системы виртуализации (это несложно - можно просто по итоговой таблице посмотреть, каких результатов достигают на таких же процах другие пользователи тестов, и дальше делать выводы), после чего опять к тесту не возвращаться, а заниматься уже планомерной работой.
Если очень-очень условно - это например как на большом электрощитке горит индикатор входного напряжения. Если он показывает нормальный уровень, то нам и дела нет до него, если же там недобор или перебор, то надо принимать срочные меры, потому как система не находится в нормальном положении.
ПубликацииОбзор облаков для 1С (часть 2)#48 29.05.20 23:52
(47) Чем APDEX хорош: это конкретная информация по конкретным информациям конкретной базы. Если правильно изначально выяснили, какие операции для базы являются ключевыми, и правильно встроили на них замеры - это и есть конечный показатель производительности информационной системы для бизнеса.
В чём его минус: его совершенно невозможно сравнивать между разными системами. Размеры баз отличаются, распределение размеров и наполнения таблиц отличается, даже понимание целевого времени у разных компаний может отличаться (тем 5 секунд за счастье, а этим 2 гипермного). И самое главное - если вдруг апдекс нехорош, то как понять, насколько в этом виновата сторона конфигурации/платформы 1С, а насколько - серверного железа и софта?
А тут пожалуйста - выполнил на двух совершенно разных системах одинаковый набор действий, получил какие-то опорные цифры, и дальше от них можно "плясать". А если вдруг на с виду похожем железе цифры почему-то серьёзно хуже, чем ожидалось - отличный повод вдумчиво разобраться, найти причину торможений, а когда она будет устранена - убедиться, что помогло. "План прост, в этом его красота" ©
ПубликацииОбзор облаков для 1С (часть 2)#36 28.05.20 13:02
(35) Лично знакомые люди, работающие через настроенный профессионалами 1с фреш, регулярно жалуются, как оно медленно работает или вообще тормозит, причём ситуация мягко говоря не разовая, а в течение последних минимум двух лет. Ну или просто показывают экраны с ошибками вида "я в базе сижу одна, не могу записать изменённый элемент справочника, получаю ошибку на таймауте регистрации изменений этого справочника". Методики и тесты могут быть отличными, а результат - отличный от хорошего.