Этого треда уже нет.
Это копия, сохраненная 23 апреля 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 23 апреля 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
24 Кб, 960x300
Есть кто много работает с PostgreSQL и 1С? сейчас переводим файловую базу на эту СУБД и вроде норм работает, но вот в номенклатуре ставишь цены и начинает по 3 секунды думать, а в файловом варианте все мгновенно считает
Тест Гилева показывает 32 балла
Почему притормаживает не можем понять
1С-ник говорит, что доработки не нужны при переходе с файловой на СУБД, а я думаю, что при переходе оптимизация в любом случае нужна, также мы используем SSD и конфиг PG вроде на максимум выкручен
Может быть надо еще быстрее диски? PCI-E например под запись в 1000МБ и чтение в 1500МБ?
СУБД пробуем и на винде и на линуксе - на линуксе 32 балла в Гилевском, на винде 22 балла
Может есть какие-то версии PG, линукса и 1С, которые совместно работают отлично?
Пробовал PG 9.2, 9.6, 11.1 на CentOS6, UbuntuServer14.04 и PG 9.6, 10.5 на Win2013R2
1С 8.3 КА
брал готовые сборки 9.2, 9.6 для линукса с сайта официального сайта 1С и PostgrePro там тоже для 1С сборки
для винды 9.6 и 10.5 с официального сайта 1С
то есть пробовал разные миксы для 1С, кроме 11.1 она сама по себе просто самая последняя. Может есть какие-то отличные проверенные версии? 1С 8.3.13.1690, база 25Гб, хотя сейчас на файловой работают на старой версии 8.3.6
сервер с 24 ЦПУ, 25Г ОЗУ, ССД с 200МБ запись\400МБ чтение для баз и системы
а конфиг большой
основные параметры для_винды:
users=100
ssl=off
shared_buffers = 2GB
temp_buffers = 16MB\t
work_mem = 16MB\t\t
maintenance_work_mem = 256MB
bgwriter_delay = 100ms\t\t\t
bgwriter_lru_maxpages = 1000\t\t
bgwriter_lru_multiplier = 4.0
max_worker_processes = 24\t\t
max_parallel_workers_per_gather = 12
wal_level = minimal\t\t\t
fsync = off\t\t\t\t
synchronous_commit = off\t\t
wal_sync_method = fsync\t
wal_buffers = 16MB
checkpoint_timeout = 60min\t\t
max_wal_size = 3GB
min_wal_size = 1GB
checkpoint_completion_target = 0.8
archive_mode = off
enable_mergejoin = off
enable_nestloop = off
random_page_cost = 1.1
effective_cache_size = 18GB
default_statistics_target = 500
join_collapse_limit = 1\t
autovacuum = on\t\t\t
autovacuum_max_workers = 20\t\t\t\t\t\t
autovacuum_naptime = 20s\t\t
autovacuum_vacuum_scale_factor = 0.005
autovacuum_analyze_scale_factor = 0.02
escape_string_warning = off
standard_conforming_strings = off
для_линукса:
users=100
ssl=off
shared_buffers = 5GB
temp_buffers = 16MB\t
work_mem = 16MB\t\t
maintenance_work_mem = 1500MB
bgwriter_delay = 100ms\t\t\t
bgwriter_lru_maxpages = 1000\t\t
bgwriter_lru_multiplier = 4.0
max_worker_processes = 24\t\t
max_parallel_workers_per_gather = 12
wal_level = minimal\t\t\t
fsync = off\t\t\t\t
synchronous_commit = off\t\t
wal_sync_method = fsync\t
wal_buffers = 16MB
checkpoint_timeout = 60min\t\t
max_wal_size = 4GB
min_wal_size = 2GB
checkpoint_completion_target = 0.9
archive_mode = off
enable_mergejoin = off
enable_nestloop = off
random_page_cost = 1.1
effective_io_concurrency = 200
effective_cache_size = 18GB
default_statistics_target = 100
join_collapse_limit = 1\t
autovacuum = on\t\t\t
autovacuum_max_workers = 20\t\t\t\t\t\t
autovacuum_naptime = 20s\t\t
autovacuum_vacuum_scale_factor = 0.005
autovacuum_analyze_scale_factor = 0.02
escape_string_warning = off
standard_conforming_strings = off
Тест Гилева показывает 32 балла
Почему притормаживает не можем понять
1С-ник говорит, что доработки не нужны при переходе с файловой на СУБД, а я думаю, что при переходе оптимизация в любом случае нужна, также мы используем SSD и конфиг PG вроде на максимум выкручен
Может быть надо еще быстрее диски? PCI-E например под запись в 1000МБ и чтение в 1500МБ?
СУБД пробуем и на винде и на линуксе - на линуксе 32 балла в Гилевском, на винде 22 балла
Может есть какие-то версии PG, линукса и 1С, которые совместно работают отлично?
Пробовал PG 9.2, 9.6, 11.1 на CentOS6, UbuntuServer14.04 и PG 9.6, 10.5 на Win2013R2
1С 8.3 КА
брал готовые сборки 9.2, 9.6 для линукса с сайта официального сайта 1С и PostgrePro там тоже для 1С сборки
для винды 9.6 и 10.5 с официального сайта 1С
то есть пробовал разные миксы для 1С, кроме 11.1 она сама по себе просто самая последняя. Может есть какие-то отличные проверенные версии? 1С 8.3.13.1690, база 25Гб, хотя сейчас на файловой работают на старой версии 8.3.6
сервер с 24 ЦПУ, 25Г ОЗУ, ССД с 200МБ запись\400МБ чтение для баз и системы
а конфиг большой
основные параметры для_винды:
users=100
ssl=off
shared_buffers = 2GB
temp_buffers = 16MB\t
work_mem = 16MB\t\t
maintenance_work_mem = 256MB
bgwriter_delay = 100ms\t\t\t
bgwriter_lru_maxpages = 1000\t\t
bgwriter_lru_multiplier = 4.0
max_worker_processes = 24\t\t
max_parallel_workers_per_gather = 12
wal_level = minimal\t\t\t
fsync = off\t\t\t\t
synchronous_commit = off\t\t
wal_sync_method = fsync\t
wal_buffers = 16MB
checkpoint_timeout = 60min\t\t
max_wal_size = 3GB
min_wal_size = 1GB
checkpoint_completion_target = 0.8
archive_mode = off
enable_mergejoin = off
enable_nestloop = off
random_page_cost = 1.1
effective_cache_size = 18GB
default_statistics_target = 500
join_collapse_limit = 1\t
autovacuum = on\t\t\t
autovacuum_max_workers = 20\t\t\t\t\t\t
autovacuum_naptime = 20s\t\t
autovacuum_vacuum_scale_factor = 0.005
autovacuum_analyze_scale_factor = 0.02
escape_string_warning = off
standard_conforming_strings = off
для_линукса:
users=100
ssl=off
shared_buffers = 5GB
temp_buffers = 16MB\t
work_mem = 16MB\t\t
maintenance_work_mem = 1500MB
bgwriter_delay = 100ms\t\t\t
bgwriter_lru_maxpages = 1000\t\t
bgwriter_lru_multiplier = 4.0
max_worker_processes = 24\t\t
max_parallel_workers_per_gather = 12
wal_level = minimal\t\t\t
fsync = off\t\t\t\t
synchronous_commit = off\t\t
wal_sync_method = fsync\t
wal_buffers = 16MB
checkpoint_timeout = 60min\t\t
max_wal_size = 4GB
min_wal_size = 2GB
checkpoint_completion_target = 0.9
archive_mode = off
enable_mergejoin = off
enable_nestloop = off
random_page_cost = 1.1
effective_io_concurrency = 200
effective_cache_size = 18GB
default_statistics_target = 100
join_collapse_limit = 1\t
autovacuum = on\t\t\t
autovacuum_max_workers = 20\t\t\t\t\t\t
autovacuum_naptime = 20s\t\t
autovacuum_vacuum_scale_factor = 0.005
autovacuum_analyze_scale_factor = 0.02
escape_string_warning = off
standard_conforming_strings = off
>>7113 (OP)
Это что за такие контроллеры, которые позволяют писать на такой скорости? Квантовые компьютеры? Или это тесты линейной read/write? Тогда просто иди на хуй.
Потому что вы долбоебы, которые не могут в трассировку и оптимизацию, а учитывая
Вы сосете писю каждого, ибо так заведено в ру$$ком говно-ентерпрайзе.
А вообще, чел, рили, иди на хуй. У тебя очевидная classic проблема в запросах или базе и никто на всей борде за тебя ее решать не будет.
> PCI-E например под запись в 1000МБ и чтение в 1500МБ?
Это что за такие контроллеры, которые позволяют писать на такой скорости? Квантовые компьютеры? Или это тесты линейной read/write? Тогда просто иди на хуй.
>Почему притормаживает не можем понять
Потому что вы долбоебы, которые не могут в трассировку и оптимизацию, а учитывая
>1С
Вы сосете писю каждого, ибо так заведено в ру$$ком говно-ентерпрайзе.
А вообще, чел, рили, иди на хуй. У тебя очевидная classic проблема в запросах или базе и никто на всей борде за тебя ее решать не будет.
>>7113 (OP)
Смотри, утилизирует ли система диски при запросах. Если нет, то ищи, кто жрёт процессорное время и устраняй.
Ну и да, двачую этого: >>7129
По моему очевидно, что да. Пацаны про IOPS-ы не слышали же.
Смотри, утилизирует ли система диски при запросах. Если нет, то ищи, кто жрёт процессорное время и устраняй.
Ну и да, двачую этого: >>7129
> Или это тесты линейной read/write?
По моему очевидно, что да. Пацаны про IOPS-ы не слышали же.
>>7113 (OP)
Хз как на вашем этом постгресе.
Но когда перекатывали эту одинэс парашу на mssql просто так захерачить ее мало.
Надо было настраивать на самой БД в mssql обновление статистки и дефрагментацию индексов. Иначе через какое то время начинала работать как говно.
Закинул это всем план обслуживания и по расписанию теперь все это выполняется и не хуя больше не тормозит.
База больше 200Гб если что.
Хз как на вашем этом постгресе.
Но когда перекатывали эту одинэс парашу на mssql просто так захерачить ее мало.
Надо было настраивать на самой БД в mssql обновление статистки и дефрагментацию индексов. Иначе через какое то время начинала работать как говно.
Закинул это всем план обслуживания и по расписанию теперь все это выполняется и не хуя больше не тормозит.
База больше 200Гб если что.
>>7314
в ПГ тоже есть и все настроено, но чот не помогает
в ПГ тоже есть и все настроено, но чот не помогает
>>7684
Эти новые новенькие
Эти новые новенькие
>>7113 (OP)
сервак 1с-ки в вертуалке?
сервак 1с-ки в вертуалке?
>>8189
и на физике и в виртуалке
я пробовал разные комбинации
самые быстрые это когда на одной машине и 1с и субд
и на физике и в виртуалке
я пробовал разные комбинации
самые быстрые это когда на одной машине и 1с и субд
>>8190
сервак 1с (сама служба) хуева работает с виртуалкой, часто появляются тормоза. и к тому же он болезненно реагирует на "слабые" по частоте ядра. т.е. лучше меньше но быстрее. гавно еще то.
попробуй 8.3.14. а вообще посмотри загрузку процессора и памяти процессом сервера 1с. если баз несколько то настрой сервер 1с так что бы запускался отдельный процесс для каждой базы.
и вообще запусти сервер 1с там где самые быстрые ядра, склюль конечно желательно там же.
сервак 1с (сама служба) хуева работает с виртуалкой, часто появляются тормоза. и к тому же он болезненно реагирует на "слабые" по частоте ядра. т.е. лучше меньше но быстрее. гавно еще то.
попробуй 8.3.14. а вообще посмотри загрузку процессора и памяти процессом сервера 1с. если баз несколько то настрой сервер 1с так что бы запускался отдельный процесс для каждой базы.
и вообще запусти сервер 1с там где самые быстрые ядра, склюль конечно желательно там же.
>>8190
и да, можешь протестить на MSSQL, но вангую что база только чуток шустрее будет и проблема не в SQL
и да, можешь протестить на MSSQL, но вангую что база только чуток шустрее будет и проблема не в SQL
>>8192
тестю на одной базе
и запускаю на самом быстром серваке
я вот наоборот думаю поставить старую 1с на которой клиенты работают
тестю на одной базе
и запускаю на самом быстром серваке
я вот наоборот думаю поставить старую 1с на которой клиенты работают
>>7113 (OP)
explain analyze тебе в руки
explain analyze тебе в руки
Тред утонул или удален.
Это копия, сохраненная 23 апреля 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 23 апреля 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.