xmolex
Константин Титов

(17)

Цитата
А есть уверенность, что в момент потери связи между серверами 1С были записаны все необходимые движения?

Я говорил про сервера postgresql, а не 1с. Уверенности конечно нет, но т.к. бэкап делается средствами 1с, то 1с при обнаружении испорченных данных в документе его просто не выгрузит в бэкап. В результате структура базы будет цела, правда за минусом документа.

(33) Это естественно, т.к. RAID5 - это не просто несколько дисков, чтобы pg мог кидать на них порции данных, это постоянный расчет контрольных сумм. Вообще, как по мне, RAID5 и highload несовместимые понятия.

(15)

Цитата
там снэпшот создается, так что итоговый бэкап полу

Не знаю как насчет терабайт, а вот с базой 300Гб (select pg_database_size('base');), которая используется 24/7/365, я сначала был такого же мнения как и вы. Бэкап делался минут 40, в течении которых пользователи плевались и матерились, т.к. предприятие тормозило еще как. Так вот в один прекрасный день, когда неудачно прошло обновление конфигурации и база отказалась запускаться, пришлось воспользоваться самым свежим бэкапом, сделанным таким путем, и каково же было мое недоумение, когда он загрузился без проблем, но при открытии в 1с счет фактур предприятие вылетало. Вы можете возразить, что мол кеши надо было чистить, но все это конечно было сделано. Сейчас система переделана. Два сервера: один мастер, другой слейв. Когда нужно сделать бэкап, слейв теряет соединение с мастером, к нему подключается сервер 1с предприятия и средствами 1с делают бэкап. После этого слейв подключается к мастеру и синхронизируется.
Снепшот может и создается (хотя не уверен, а проверять ваши слова лень), но это снепшот sql базы. А вот 1с в этот момент может что-то активно писать и поменять данные в 1 таблице sql, и тут произойдет снепшот sql, а еще в 10 таблицах не успеет поменять, хотя должна, чтобы поддерживать свою логику. Вы же знаете, что одно добавление в регистр записи, может запускать множество других регистраций и каждая из них будет запускаться как одна транзакция в sql. Поэтому данные в базе у вас обязательно испортятся. Возможно база у вас и загрузится и даже работать будет, но данные будут неполными и это аукнется позже.

(11)

Цитата
м делать бэкап базы не выг

Нет, нельзя. Одна операция в 1с меняет данные во многих sql таблицах. Бэкап базы существеннен по времени и у вас нет гарантии, что данные за это время не изменятся. Вы сделаете несколько бэкапов и они будут рабочие, но однажды попадете на восстановление данных.

Хотел бы немного упомянуть про очень интересный параметр, если у вас диск в рейд0: effective_io_concurrency. Очень хорошо влияет на производительность.

Расскажу о самой большой базе с которой мы работаем. Предприятие работает в режиме 24 часа 365 дней в году.
УПП, в котором производство, учет и продажи. Работают около 50 активных пользователей.
Размер базы в sql за 340Гб. Некоторые индексы около 12Гб. База одна. Стоит на CentOS 7, postgreSQL 9.1.9x64. На сервере с базой рейд 10 из 6 дисков sata3 и 64Гб оперативной памяти. Сервер 1с предприятия на другой машине.

(26) sirm, на различные ошибки конечно. Если в логах нет никаких ошибок и внеплановых вылетов, значит проблема не в postgresql и копать нужно в сторону сервера 1с, конфигурации и толстого клиента.

(24) sirm, тестирование и исправление.
Что значит "Особых ошибок не увидел", они либо есть, либо их нет.
В конфиге log_min_error_statement = error стоит, может не ведутся логи?

(20) sirm, если проблема с postgresql, то лезь в его логи и ищи там ошибки. Если найдешь ругань при запуске расчета себестоимости, то значит проблема в postgresql. В зависимости от типа ругани и следует выбирать направление действий. А вот, если ругани нет, то стоит обратить внимание на сервер 1с предприятие: проверить правильность данных в конфигурации, обнулить рабочий каталог сервера 1с предприятие и т.д.

(16) ansh15,
Все зависит от особенностей использования системы. У нас очень часто правятся накладные задним числом, тоесть в день происходит тысячи перепроведений документов. Пока такой сервер справляется, но думаю, что при таком же росте базы через год уже будут тормоза.
Но вообще, когда у вас база сильно превышает оперативку, вам стоит очень серьезно подойти к дисковой подсистеме. У нас стоит рейд 0 из двух sas (2.0) дисков.

(17) mirco,
Я бы не сказал, что я обижаюсь. Я просто не понимаю вас, но способен принимать критику от более опытных товарищей. Я работаю с postgresql уже семь лет (вначале была разработка интернет-проектов). И всегда я видел, что postgresql требователен к скорости диска и оперативке. Об этом и пишут и сама эксплуатация это показывает. Возьмем сервер 1с:предприятие. Ему также нужна память. Приплюсуем сюда рекомендацию запускать более одного рабочего процесса и вот у нас уже съедается два гига оперативы, приплюсуем операционку (которая в идеале расчитывает на два гига оперативы, т.к. без ключа /3Gb), приплюсуем терминальные сессии с 30 пользователями, которые запустили 1с и который с легкостью может скушать 512Mb, это еще гигов под 14. И что получается? А получается, что по памяти система и так загружена по самое нихочу (не забудем про то, что win очень активно работает с swap файлом, хоть памяти и достаточно), а вы решаете еще вклинить в нее приложение очень требовательное к памяти, да еще и с базой >200Гб. У вас одних прерываний будет столько, что вы получите неслабый простой. Какие настройки здесь спасут? Ни один тюнинг не сможет разгрузить систему.
Конечно, если пользователи не работают, а чай пьют в 1с, то конечно система будет справляться, но если хоть один человек начнет активно данные перепроводить, вашей системе придется не слабо.
Если вы не согласны с моими словами, то прошу вас быть более аргументированнее.