Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

После перехода на новую полатформу и СУБД выкидывает пользователей

[catena, 07.11.19 - 08:46]
После перехода на новую полатформу и СУБД выкидывает пользователей
Я
   Пузан
 
06.11.19 - 06:13
Перешли сегодня на 8.3.15.1700 и PG 10.10.
До этого гоняли на тестовой базе - все путем работало.
Сейчас когда зашли все пользователи, стало периодически выкидывать пользователей с сообщением:
"Ошибка выполнения запроса
Ошибка при выполнении запроса POST к ресурсу /e1cib/modules/call:
по причине:
На сервере 1С:Предприятия произошла неисправимая ошибка. Приложение будет закрыто"

Выкидывает из всех конфигураций и свежих ЕРП и древних УПП.
Че это за такое и как с этим бороться? Может у кого было такое.
 
 
   Пузан
 
1 - 06.11.19 - 06:25
Сейчас выяснилось, что ресурс у всех разный. Т.е. вообще в разнобой. Как то может быть связано с кэшем серверным или чем то подобным?
   assasu
 
2 - 06.11.19 - 07:06
какая то срочная необходимость  в 8.3.15  вообще есть ?
   Пузан
 
3 - 06.11.19 - 07:16
(2) Просто сидели на 8.3.13, а новые конфиги уже рекомендуют 8.3.14. Посмотрели ошибки, что в 8.3.14 что в 8.3.15 одинаковые, решили на последний переходить. Тем более что есть отзывы, что он быстрее.
   Пузан
 
4 - 06.11.19 - 07:17
Ну и описанное в (0), судя по тому что пишут в инете, происходит буквально на чуть не на всех релизах начиная с 8.3.5. Так что надо понять что за проблема и как ее решать.
   МимохожийОднако
 
5 - 06.11.19 - 08:21
(0) Вчера вышел очередной релиз. Идите дальше.
   Shur1cIT
 
6 - 06.11.19 - 08:27
(0) посмотри на процессы 1с, скорее всего они перезапускаються в момент падения, изучи журналы ошибок возможно проблемы лицензирования
   evgeniy_n
 
7 - 06.11.19 - 08:52
(2) Тоже перешли на 8.3.15, ибо
"Рекомендуется использовать текущую версию конфигурации "Управление торговлей", редакция 11 с версией системы 1С:Предприятие 8 8.3.15.1489 (и выше)."
Всё виндовое, MS SQL Server.
После установки платформы 8.3.15.1565 стали возникать периодические вылеты КАМИНа (после ТиИ получше стало, но совсем не исчезло).
А вчера попробовал запустить УТ в толстом клиенте (обычно в тонком работает): постоянные вылеты.
Может, совпадение, но похоже, что дело в толстом клиенте - КАМИН как раз использует толстый клиент. В тонком таких проблем нет.
   Пузан
 
8 - 06.11.19 - 09:05
(7) У нас похоже наоборот. Щас всех заставили ходить под толстым клиентом и уже полтора часа все норм. ТЖ запустил, логи смотрю, пока никакого криминала, но пока и не рушится ничего.
   Пузан
 
9 - 06.11.19 - 09:08
(5) Ну каждый день мы не можем релизы менять. Просто пока переходили, тестировали и прочее, выпустили новый релиз и там поправлены пара незначительных ошибок.
   МимохожийОднако
 
10 - 06.11.19 - 09:25
Для статистики.
В течение недели поменял платформу 8.3.15.1700 (Две PG, одна MSQL)
Полёт нормальный
   Пузан
 
11 - 06.11.19 - 09:34
Хм, почти два часа все было норм, щас опять выкинуло, причем не всех. Может старые конфиги УПП и КА мешают современной ЕРП? Фигово что все на одном РПХосте сидит. Так можно было бы локализовать хоть на предмет какая база выглючивает.
   Пузан
 
12 - 06.11.19 - 09:36
Может в лицензии ПРОФ есть ограничение на количество соединений/сеансов? У нас в сумме свыше 256 точно бывает, если считать фоновые и вообще все.
   xXeNoNx
 
13 - 06.11.19 - 09:36
(0) ктож одновременно меняет платформу и субд?
   xXeNoNx
 
14 - 06.11.19 - 09:38
(12) чисти настройки кластера и заново настраивай
   cons24
 
15 - 06.11.19 - 09:38
ТС, не гонитесь за хотелками типовых. Типовая хочет, а платформа не может. Вот как бывает оказывается.
В смысле последние релизы (13-14-15) платформ баговатые идут. И конца и края не видно.
Откатитесь на тот релиз платформы где работало. В крайнем случае поставите отдельно службу 15ю для одной базы, а остальные будут жить спокойно.
   dmpl
 
16 - 06.11.19 - 09:39
(11) Запустите несколько агентов на разных портах.
   unregistered
 
17 - 06.11.19 - 09:50
Для начала почистить кэш на сервере.
Скрипт с 1С-овского ИТС.
Остановка службы 1С:Предприятие с очисткой временных файлов. (естественно подставить свои пути к кластеру, и имена служб).

set LOG_FILE="scripts.log"
set SERVICE_1C_NAME="1C:Enterprise 8.3 Server Agent (x86-64)"
set SERVICE_RAS_NAME="1C:Enterprise 8.3 Remote Server"
set CNTX_PATH="C:\srvinfo\reg_1541"
set PFL_PATH="C:\ProgramData\1C\1cv8"
set TEMP_PATH="C:\Windows\Temp"
echo stop %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
sc stop %SERVICE_1C_NAME%
sc stop %SERVICE_RAS_NAME%
timeout 5
taskkill /f /im "rphost.exe"
taskkill /f /im "rmngr.exe"
taskkill /f /im "ragent.exe"
taskkill /f /im "ras.exe"
timeout 5
echo done stop %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
echo clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
DEL /Q /F /S %CNTX_PATH%\snccntx*
DEL /Q /F %PFL_PATH%\*.pfl
DEL /Q /F /S %TEMP_PATH%\*.*
echo done clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%


Если баз не много (3-5), то установить в настройках рабочего сервера 1 базу на процесс.
Хотя для начала я бы попробовал наоборот - типовые настройки.
Очень странно, что при 256 сеансах у вас один rphost.
Проверьте - нет ли ограничений по памяти.
Включить ТЖ, анализировать логи падающих процессов.

PS Довольно рискованная операция - одновременная смена и СУБД, и платформы. Правильнее было бы разделить, чтобы сузить круг возможных причин любых косяков.
   Пузан
 
18 - 06.11.19 - 09:51
(13) Мы. Просто появилась возможность сделать все и сразу. Изначально стояла задача перейти на PG, а так как PG хочет не менее 14-ой, то решили не мелочиться и ставить сразу 15-ую. Естественно тестили это дело. (15) Ну 13-ая у нас пока висит, на всякий случай. (16) Тоже вариант, но щас пока смотрим как оно работает без извращений. Есть еще мнение что не почистили кэш, но админы уверяли что почистили, потому что щас выкинуло только двух пользователей, остальные работают.
   Пузан
 
19 - 06.11.19 - 09:52
(17) Кэш на сервере почистился, ибо базы полностью пересоздавали когда со скуля на PG переводили. Т.е. в оснастке удалялись и создавались заново, по крайней мере со слов админов. :)
   Пузан
 
20 - 06.11.19 - 09:53
(17) "Если баз не много (3-5), то установить в настройках рабочего сервера 1 базу на процесс.
Хотя для начала я бы попробовал наоборот - типовые настройки.
Очень странно, что при 256 сеансах у вас один rphost. " Для этого надо иметь лицензию КОРП, а тут только ПРОФ.
   evgeniy_n
 
21 - 06.11.19 - 09:56
Вдогонку к (7).
Ну вот, выходит новая конфа Торговли (ничего принципиально нового, только ошибки исправили), и вот на тебе, рекомендуют ещё более новую платформу, чем предыдущая версия конфы:
"Рекомендуется использовать текущую версию конфигурации "Управление торговлей", редакция 11 с версией системы 1С:Предприятие 8 8.3.15.1656 (и выше)."
Если совсем плохо будет, придётся как-то организовывать возможность работы двух платформ для разных БД. Раньше с таким не сталкивался.
   Пузан
 
22 - 06.11.19 - 11:05
(10) А какие конфигурации, если не секрет?
   Пузан
 
23 - 07.11.19 - 04:59
Хм. Убрали ключ -debug все заработало. Я понимаю что этот ключик зло на рабочей базе, но должно же и с ним работать. Может че с окружением не так.
   rphosts
 
24 - 07.11.19 - 05:07
(23) у вас там что, круглосуточная работа?
   rphosts
 
25 - 07.11.19 - 05:09
(23)И да, вы чистку с отменой отладки не совместили?
   rphosts
 
26 - 07.11.19 - 05:09
*чистку кэша
   Пузан
 
27 - 07.11.19 - 05:34
(25) Я вчера вечером, всех выгнал, почистил все кэши. Не помогло. Отключил отладку на сервере. Помогло. На ночь поставил закрытие месяца. Не вылетело до сих пор и пока никого за полтора часа работы не выкинуло. Но в логах много событий типа:
"00:31.881002-0,EXCP,0,process=rphost,OSThread=5664,ClientID=6802,Exception=NetDataExchangeException,Descr='server_addr=(2)192.168.3.32:59976 descr=2(0x00000002): Не удается найти указанный файл.  line=1149 file=src\DataExchangeServerImpl.cpp'"
и
"00:26.084004-0,EXCP,3,process=rphost,p:processName=ERP_SINAR,OSThread=8140,t:clientID=125,t:applicationName=BackgroundJob,t:computerName=1CSA,t:connectID=3800,SessionID=1267,Usr=Жмаева Л.Д.,Exception=SeanceContextException,Descr='Сеанс отсутствует или удален
ID=4828417a-f23b-4e5b-8c3f-f9dd08327b56, File=src\ClusterDistribImpl.cpp(1640)'"
Хотя пользователи ни на что не жалуются. Твои тезки периодически завершаются и появляются новые вместо них. :)
   Пузан
 
28 - 07.11.19 - 05:37
А вообще ЕРП на 8.3.15 и PG довольно быстро работает, по сравнению с 8.3.13 и MSSQL 2005, при прочих равных (оборудование и ОС остались теми же).
   rphosts
 
29 - 07.11.19 - 06:24
(28) сравнил версионник и блокировочник на управляемых блокировках!!! Но только пока не забываешь регулярно постгри обслуживать(бывает и раз в сутки это мало, но это про хайлоад) - он к этому более требователен чем сиквел.
   Провинциальный 1сник
 
30 - 07.11.19 - 06:32
(27) "Отключил отладку на сервере. Помогло. "
А включать отладчик по http пробовали? Просто интересно.
 
 Рекламное место пустует
   rphosts
 
31 - 07.11.19 - 06:42
(30) +1
   Пузан
 
32 - 07.11.19 - 07:02
(30) Нет. Не пробовали.
   Пузан
 
33 - 07.11.19 - 07:18
(29) А че конкретно надо регулярно запускать для обслуживания?
   rphosts
 
34 - 07.11.19 - 08:21
(33) vacuum analize - дабы похерить старые версии и обновить статистику.
   rphosts
 
35 - 07.11.19 - 08:21
+ (34) автовакуум не всегда отрабатывает...
   Провинциальный 1сник
 
36 - 07.11.19 - 08:22
(34) А что там в новых версиях постгреса со статистикой неявных временных таблиц (подзапросов), починили её? А то, помнится, он ооочень часто ошибался раньше и гонял нестед лупы.
   rphosts
 
37 - 07.11.19 - 08:38
(36)говорят стало лучше, самому некогда пощупать - работы просто пипец... вото ветка где спецов по постгри есть: Какую версию PostgreSQL ставить?
   Пузан
 
38 - 07.11.19 - 08:46
Все равно выкидывает. Значительно реже и не в таких масштабах (меня с двух разных баз выкинуло по одному разу за 4 часа), но выкидывает. Щас есть два мнения: 1. Что то с сетью или сетевыми интерфейсами. 2. На новой платформе могут работать только новые конфиги и надо убирать все старые на старую платформу.
   Пузан
 
39 - 07.11.19 - 08:48
+(38) При этом закрытие месяца работало всю ночь и еще потом два часа днем и доработало до конца без ошибок. Т.е. проблемы начались когда подтянулись пользователи. Буду пробовать добиваться чтобы все старые конфиги убрали с новой платформы.
   Shur1cIT
 
40 - 07.11.19 - 08:56
Писал уже в (6) проверьте процессы они перезапускаются ? если да проверьте логи скорее всего отваливается лицензия следовательно падает процесс который не сразу перезапускается ибо лицензия глюкнула, если конфа работает под толстым клиентом то это 100% вылет пользователя если под тонким может и незаметно пройти если падение не долгое было.
   Shur1cIT
 
41 - 07.11.19 - 08:57
(40) естественно чтобы посмотреть логи необходимо настроить технологический журнал.
   Пузан
 
42 - 07.11.19 - 09:01
(40) Да, процессы перезапускаются. Причем активно. Хотя меньше чем вчера. (41) Настроил ТЖ, но в этом потоке сообщений про лицензию не вижу ничего. Какую надо включить настройку и по какому признаку потом искать именно эти записи?
   unregistered
 
43 - 07.11.19 - 09:01
(20) >> Для этого надо иметь лицензию КОРП, а тут только ПРОФ.

А в ПРОФ эти параметры вообще закрыты для изменения или не принимаются изменения?
Я думал, что в целях эксперимента эти параметры менять всё таки можно.
   Пузан
 
44 - 07.11.19 - 09:02
(40) Выкидывает не всех и не изо всех баз. Т.е. как-то выборочно.
   Пузан
 
45 - 07.11.19 - 09:03
(43) Менять можно. Но при входе очередного пользователя ругается что параметры надо задать по умолчанию.
   unregistered
 
46 - 07.11.19 - 09:06
(44) >> Выкидывает ... выборочно.

Пробовали чистить локальный кэш у этих самых выборочных пользователей?
   Shur1cIT
 
47 - 07.11.19 - 09:08
(42) если есть возможность поставь атрибут "ALL" (возможны тормоза) чтобы всвё видеть или "SRVC" чтобы посмотреть что с сервисами происходит
   Shur1cIT
 
48 - 07.11.19 - 09:12
(46) на разных сервисах возможно народ висит при этом вылетел только один, при таком раскладе из толстого клиента выкинет в тонком пройдет не заметно на рабочей процесс переползет (если есть рабочий).
   rphosts
 
49 - 07.11.19 - 09:24
запусти пинг на долго... потом когда стопнешь через часик - посмотри % потерь. Насколько помню >0,05% - уже очень плохо
   sitex
 
50 - 07.11.19 - 09:31
(49) Тогда лучше уж писать результаты пинга в файл txt.  И потом анализировать.
   Пузан
 
51 - 07.11.19 - 09:39
(46) Это первое что сделали. Меня тоже выкинуло.
   unregistered
 
52 - 07.11.19 - 09:40
(49) +. Пинг с параметром /L60000. 1С очень любит пакеты большого размера, а потерь и задержек в их передаче может быть на порядок больше, чем при обмене пакетами стандартного размера.
Вообще по сети - убедиться, что везде отключен IPv6 (на сервере и на клиентах), нет косяков с маршрутизацией.
На сервере и на клиентах нигде не включены в ОС режимы энергосбережения (может админы "оптимизировали" что-то массово), а так же в диспетчере устройств в параметрах сетевых карточек не разрешено отключение и/или перевод устройства в спящий режим для экономии энергии.

Но вообще сомнительно, что проблемы сети вылезли одновременно со сменой СУБД и платформы.
   Пузан
 
53 - 07.11.19 - 09:40
(49) Пинг с какой машины и до какой?
   Пузан
 
54 - 07.11.19 - 09:42
(52) Ну если что, то можем быстро переползти обратно на 8.3.13. Щас пока работаем. Но думаю что в итоге так и поступим.
   unregistered
 
55 - 07.11.19 - 09:42
(53) От клиента к серверу. На машине проблемного пользователя ping SERVER1C....
   Фрэнки
 
56 - 07.11.19 - 09:42
(45) не очередного, а примерно после 10-го пользователя.

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

И не можешь подсказать, на какой типовой уже нужно релиз платформы 8.3.14+ ?
   Фрэнки
 
57 - 07.11.19 - 09:44
(54) Я бы на 8.3.13 не рисковал, точнее говоря, успешно его пропустили и сели на 8.3.14.1779
В сентябре вернули параметры на дефолтные и продолжаем пока сидеть на нем.
   Пузан
 
58 - 07.11.19 - 09:44
(56) Нужно ни на какой, а рекомендуется уже на последней ЕРП. Ну и с PG 10.10 тоже рекомендуется уже 8.3.14, хотя еще пару недель назад было 8.3.15, потом поменяли почему то, может именно по этому.
   Пузан
 
59 - 07.11.19 - 09:45
(57) Если на 8.3.14, то это снова на неделю минимум подготовка, чтобы у всех ее установить.
   rphosts
 
60 - 07.11.19 - 09:45
(53) с на какой валится до сервера 1С, если серверов несколько - до каждого из них.
   Пузан
 
61 - 07.11.19 - 09:49
(52) Точно -l 60000? У меня при таком параметры 100% потери пакетов.
   Пузан
 
62 - 07.11.19 - 09:50
(55) Нет проблемного пользователя. Всех с разной периодичностью выкидывает.
   unregistered
 
63 - 07.11.19 - 09:52
(58) >> пару недель назад было 8.3.15, потом поменяли почему то, может именно по этому.

Нет. Не поэтому.
Во-первых, там указано НЕ НИЖЕ(!!!) 8.3.14.
Во-вторых, есть процедура тестирования СУБД для работы с каждой версией платформы. Только когда весь протокол успешно соблюдён публикуют информацию о требованиях по совместимости.
Если бы была проблема с 8.3.15, об этом написали бы в файлике об особенностях СУБД.
   hhhh
 
64 - 07.11.19 - 09:54
(63) не ниже 8.3.12 вроде. Чего вы нас путаете? Это рекомендованная 8.3.14, это разные вещи, неи ниже и рекомендованная.
   unregistered
 
65 - 07.11.19 - 09:57
(61) Да. /l 60000. Потери могут быть но незначительные.
Можешь попробовать с меньшими значениями. Например, с 1000.
   unregistered
 
66 - 07.11.19 - 10:00
(64) Никто никого не путает. Я писал на сообщение автора ветки в (58) о версии СУБД PG 10.10.
Она (PG 10.10) работает с платформой НЕ НИЖЕ 8.3.14. То есть вполне совместима с 8.3.15.
При откате на 8.3.13 использование PG 10.10 на свой страх и риск. Вроде как, должно работать, но это не точно и 1С это не проверяла.
 
 Рекламное место пустует
   sitex
 
67 - 07.11.19 - 10:00
(61) Ну значит у вас стоит оборудование которое не тянет. коммутаторы/свитчи не все тянут или игнорируют больше заявленного размера.
   unregistered
 
68 - 07.11.19 - 10:03
ОФФ. Вообще странно, что сплошь и рядом встречается игнорирование требований совместимости со стороны пользователей и непонимание того, чем отличается "необходимо" от "рекомендуется" и требования к конфигурации и к СУБД.
   unregistered
 
69 - 07.11.19 - 10:05
(61) У вас сеть точно проводная, не WiFi?
Проверьте маршрутизацию. Через сколько коммутаторов проходят пакеты. Может админы что-то накосячили или действительно какой-нибудь коммутатор глючит или накрылся вовсе.
   Фрэнки
 
70 - 07.11.19 - 10:06
PostgreSQL, версия 10.10-1.1C

Внимание! Текущая версия PostgreSQL предназначена для использования с версией технологической платформы 1С:Предприятие 8 не ниже 8.3.14.1565
   Garykom
 
71 - 07.11.19 - 10:08
(69) Или выяснится что петля в сетке и как только нагрузка на локалку слега вырастает ("когда зашли все пользователи") сетевой шторм начинается ))
   sitex
 
72 - 07.11.19 - 10:10
Админам скажи чтоб iPerf -ом проверили  и в НЕ рабочее время. А то всю локаль положат.
   ansh15
 
73 - 07.11.19 - 10:29
(36) https://forum.infostart.ru/forum86/topic229257/#message2327174
В 7-ом сообщении текст запроса на 1С и его трансляция в PostgreSQL.
Не думаю, что довели оптимизатор до такого состояния, чтобы он с легкостью работал с подобным. Жаль, что нет плана этого запроса.
   Провинциальный 1сник
 
74 - 07.11.19 - 10:35
(73) Джойн с подзапросом - тяжелый случай для постгреса всегда был. А в 1с это сплошь и рядом, ибо виртуальная таблица регистра это по сути подзапрос. Суть в том, что на момент формирования плана основного запроса еще нет информации о том, какова будет статистика подзапроса, и оптимизатор её оценивает как-то эвристически. И в большинстве случаев предполагает, что результат будет мелкий, а в 1с он как правило большой. Тут всю систему надо менять, отказываться от принципа формирования плана "сверху вниз", в сторону формирования плана "снизу вверх" с выполнением подзапросов ДО формирования плана запроса верхнего уровня. Но это вряд ли будет в постгресе.. никому кроме 1с это не надо.
   bolobol
 
75 - 07.11.19 - 10:42
(65) /l 60000 - 100% потерь во все стороны, /l 6000 - норм. Уверен, что нолями не ошибся? Проблем с сетью, с 1С нет.
   rphosts
 
76 - 07.11.19 - 10:59
(71) от петли обычно в итоге сеть ложится
   unregistered
 
77 - 07.11.19 - 11:03
(75) Уверен. Нолями не ошибся. 60000 - это максимально возможный размер буфера (точнее - 65536).
Насколько большими пакетами обменивается 1С - я не знаю. Вполне возможно, что и 1000 достаточно.
У меня с 60000 потерь нет.
   bolobol
 
78 - 07.11.19 - 11:07
(77) Даже при /l 20000 - потери: 50%
   sitex
 
79 - 07.11.19 - 11:25
(78) То что потери при больших пакетах это еще ничего не говорит.
   Пузан
 
80 - 07.11.19 - 11:38
(77) Между сервером 1С и сервером PG ставил 60000 - норм. Между моим компом и сервером 1С 100% потери, может из-за того что 100Мб сеть или куча всякого между нами. Но до перехода на 8.3.15 все же работало. Что интересно оно и на тестовом сервере, в котором пользователи на корпии базы всякое крутили, все работало норм.
   rphosts
 
81 - 07.11.19 - 13:05
(80) а у вас там до кучи админы что-то перепилить не решились пока вы платформу и базовод не апнули?
   H A D G E H O G s
 
82 - 07.11.19 - 13:10
(0) В 8.3.15 при обновлении агрегатов оборотного регистра накопления падает rphost.exe
Во всех типовых современных типовых есть такое регзадание, которое пытается выполниться, валит rphost, менеджер создает новый, перекидывает туда сеансы и рег задание, рег задание пытается исправить свою ошибку и выполниться вновь, валит rphost.....

Ошибка зарегана, обещали поправить.
Мы у себя отключили пересчет агрегатов, пусть отчеты будут тормознее.
   H A D G E H O G s
 
83 - 07.11.19 - 13:14
   Пузан
 
84 - 07.11.19 - 16:34
(82) Спасибо, попробуем.
   Пузан
 
85 - 07.11.19 - 16:39
Регл. задание Обновление агрегатов отключено. Агрегатами вообще не дает никак управлять. Т.е. погашены закладки и кнопки касающиеся агрегатов.
   rphosts
 
86 - 07.11.19 - 17:32
(82)ээээ, если корп и серверов есть - все фоновые можно подальше засунуть.
И да, теоретически пересчитывать можно средствами постгри, но нужно скрипт запилить.
   Пузан
 
87 - 11.11.19 - 10:01
Что то совсем все плохо. Щас при проведении документов начало ругаться что объект не найден. Все встало колом. PG жрет процессор под 100%, при этом все висит. Какой-то так себе опыт перевода на PG получается. :)
   Пузан
 
88 - 11.11.19 - 10:03
Или мы не умеем ее готовить или ERP 150Г и 150 пользователей в принципе не способна работать на PG.
   ansh15
 
89 - 11.11.19 - 10:31
(87) В БГУ 1.0 на PostgreSQL 10.10 проведение одного из документов(внутреннее перемещение) может приводить к такому же эффекту, причем еще занимается вся доступная память, включая своп, после чего процесс postgres самоубивается с криками "Out of memory!" и всех выкидывает.
enable_nsetloop=off не помогает.
На 9.6.7 и 11.5 такого происходит.
   ansh15
 
90 - 11.11.19 - 10:43
К (89) Такого не происходит.
   ansh15
 
91 - 11.11.19 - 10:44
А "объект не найден" больше похоже на платформу, чем на СУБД. Может, совокупность версий конфигурации и платформы.
   Пузан
 
92 - 11.11.19 - 11:03
(91) Может. Просто чем дальше тем хуже. Возможно с индексами проблема, хотя делали реиндекс базе. Щас наверное откатим на MS SQL, а на копии посмотрим че это за фигня. Проблема конкретного документа или с базой чета. Тут вообще все странно, отражение в регл. учете запускается, в регистре к отражению все документов 30, но он часами не может их отразить, фоновое задание висит и только в размерах пухнет.
   Пузан
 
93 - 12.11.19 - 07:19
Хм. Короче. Выяснилось что упирается в дисковую подсистему. Длинная очередь к диску. Даже крутой рейд 10 не помогает. Поставили базу на SSD 970 EVO PLUS - все начало летать, право пока только половина пользователей ее нагружают, но раньше все висело даже на меньшем количестве. PG любит быстрые диски. Ну таки SDD даже если каждый год менять, то это все-равно дешевле, чем покупать новый MS SQL, раз так в 50. :) Щас вот думаем, таки в продакт завести SSD или воспользоваться вредными советами и отключить fsync и прочее, ибо типа на рейде есть батарейка и не страшно.
   Провинциальный 1сник
 
94 - 12.11.19 - 07:55
(93) А включить асинхронную запись в постгресе пробовали?
   Пузан
 
95 - 12.11.19 - 08:03
(94) Нет пока. Админы тут посмотрели статистику и выяснили что просела производительность дисков. Короче, расследование показало очевидную вещь. У PG куча мелких файлов и он в процессе работы еще не меньшую кучу создает. Т.е. нужен быстрый произвольный доступ, что SSD конечно предоставляет с легкостью, а массив на SAS, пусть даже серверных дисках, не может. Отсюда же понимание почему у MS SQL не было таких проблем - там два больших файла на базу и еще несколько служебных и нужно быстрое последовательное чтение, что конечно уже рейд легко дает. Так что пока ситуёвина такая: если хотите переходить на PG да еще с большими и нагруженными базами, то нужны SSD или какие-то другие массивы с большой скоростью произвольного доступа.
   Провинциальный 1сник
 
96 - 12.11.19 - 08:17
(95) Ну это понятно. Просто интересно, проседает ли производительность с включенной асинхронной записью, то есть очередь возникает на чтение или на запись.
Тут дело скорее не с количеством файлов как таковым. Ведь внутри этого большого файла базы mssql по сети так же куча "файлов" - таблиц, индексов, метаданных. Возможно связано с особенностью работы винды с большими каталогами, когда при обращении к любой таблице происходит обращение к каталогу, а в случае каких-то проблем с индексами ntfs оно очень медленное, так как производится последовательный поиск.
   Провинциальный 1сник
 
97 - 12.11.19 - 08:20
+(96) "по сети" читать как "по сути")
   ansh15
 
98 - 12.11.19 - 10:51
(93) На RAID контроллере с кэшем и батарейкой и(тем более) SSD влияние fsync почти не заметно, можно даже full_page_writes включить для большей безопасности.
Еще PostgreSQL любит, чтобы вся база(или большаяя ее часть) была в shsred buffers, а shared buffers можно поместить  в huge pages, huge page сделать размером в 1ГБ..
Еще всем процессам PostgrSQL(autovacuum, сборщик статистики, bgwriter) нужны незанятые ядра, чтобы не тормозить.
   H A D G E H O G s
 
99 - 12.11.19 - 11:15
Поставили SSD
Пользователи стали более лучше и быстрее переключаться с упавшего rphost-а :-)
profit
   Пузан
 
100 - 12.11.19 - 11:27
(99) Ну это да, это косяк платформы. :) Будем переходить на 8.3.16, там в последнем вроде как раз эти косяки с падением процессов пофиксили. Но вообще это конечно засада. После 8.3.12 ни одного стабильного релиза. Они бы вместо всяких, мало кому нужных, рюшечек довели бы до ума платформу, чтобы она тупо не падала от любого чиха. А то похоже на продукцию АвтоВАЗа еще лет 10 назад, когда в рассыпающемся ведре с болтами кучу всяких наворотов, которые тоже через раз работают.


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.