Всем привет!
Ребят, подскажите, что с производительностью творится?
Конфигурация железа:
ОС - Ubuntu 10.04
ядро - 2.6.32-39-generic-pae
MB - S1200BTL
CPU - Intel(R) Xeon(R) CPU E31225 @ 3.10GHz
RAM - 16 GB
база на RAID1 или RAMDISC  - пофиг
сервер 1С - 8.2.15.294
PostgresQL - 8.4.4-eter2ubuntu

Тест Гилева показывает 17-21.

Ключевые параметры PostgresQL:
<1c>
shared_buffers = 256MB
temp_buffers = 32MB
work_mem = 16MB
maintenance_work_mem = 256MB
fsync = off
synchronous_commit = off
full_page_writes = off
wal_buffers = 2048kB
commit_delay = 50
commit_siblings = 7
checkpoint_segments = 8
checkpoint_timeout = 5min
random_page_cost = 2.0
cpu_tuple_cost = 0.001
cpu_index_tuple_cost = 0.0005
effective_cache_size = 4096MB
default_statistics_target = 100
autovacuum = on
deadlock_timeout = 2s
max_locks_per_transaction = 250
</1c>
postgresql.conf
http://narod.ru/disk/43006523001.239c08fe1b645e73592aed6337f101cf/postgresql.conf.html

Че за тест Гилева?

(1) Была у него в свободном доступе приблуда. показывающая производительность.

(2) В точку

поделитесь кто-нить

(0)а ссылка на тест есть?

http://narod.ru/disk/43007417001.15b62cfdabcbb46477a82a329a475c7f/tpc1ca.rar.html

благодарю

(7)Не за что, результаты отпишите, кто тест прогонит.

(8)всё равно спасибо )))

(8) После выходных отпишусь.
На сегодня рабочий день закончен

а почему 32-х битка?

(11)Потому что денег на 64 не дали, жлобы(

копм локальный 54,35 файловая
виртульный тестовый сервак 16,39 скуль
рабочий сервак 19,23 скуль

(13)файловую с сервером сравнивать смысла 0, а конфигурацию сервера отпишите пжлста.

(13)Виртуалка какой?

из (0) результаты это сервер воткнут на железо, в виртуалке, KVM, производительность ~10

(0)Посмотрите в /proc/cpuinfo, может у вас процессор на пониженной частоте работает, cpuspeed включен или еще что...

Xeon E5420, 2.5GHz - 35
Xeon E7-4870, 2.4 GHz - 42
AMD Phenom 9850, 2.5 GHz - 19-22

Везде CentOS и PostgreSQL х86_64, разные версии платформ(как 32-х, так и 64-х разрядные).

(17)Ок, заглянем.
(18)Принял.

(18)Залей на народ конфиг пжлста.

+(20)CentOS версия, ядро?

(20) Подожди немного, сейчас погоняю на Xeon E5420 с разными значениями shared_buffers
(21) Разные, 5.7, 6.2. PostgreSQL тоже разных версий, правда, от 1С и самосборный.

(20)
shared_buffers = 2048MB
temp_buffers = 8MB
work_mem = 8MB
maintenance_work_mem = 1024MB
fsync = off
synchronous_commit = off
full_page_writes = off
wal_buffers = -1
checkpoint_segments = 40
enable_nestloop = off
effective_cache_size = 4096MB
max_locks_per_transaction = 150
escape_string_warning = off
standard_conforming_strings = off

В принципе, shared_buffers не влияет, как оказалось, что 64MB, что 2048MB. Во всяком случае для этого теста.
Как впрочем и остальные параметры, управляющие памятью для постгрес. Пробовал менять в разные стороны из перечисленных
Стабильно 34-35 баллов. Память на сервере - 16ГБ.

(17),(23) Спасибо, все угадал, по тестал за 30 баллов ушли.
С меня поллитру.)

47 на домашнем.

на рабочем 87,72
на сервере 12,5 - хз почему такая цифра, сервера вроде не слабые (все на винде и мсскл)

+(26) во время замера на серверном варианте выскочила ошибка COM (сервак x64), может в этом причина?

(25),(26)Файловая база то с высокими показателями?

(14)(15)низя

(29)ПечалькО

(26) файловая - 87,72

перевел конфу в режим 8.2.13, результат поднялся до 15

(31)Не идет в сравнение, у нас тоже заоблачная производительность на файловой базе) Проблема ребром встала именно с базой на postgresql. Оказалось и правда производительность процессоров была занижена.

(32)=)

(33) на файловой i7 разогнанный  16гб оперы и базой на ssd

Еще подскажите по параметру enable_nestloop, я так понял он влияет на поведение планировщика запросов? Т.е. позволяет строить оптимальный план запроса с/без использования вложенный циклов и слияний?

(36)Там слегка мутная тема. У меня enable_nestloop выключен постоянно, потому что иначе в БГУ ведомость основных средств и НПА(кажется, так называется) глухо виснет, потому что в запросе для постгрес содержится некоторое количество вложенных запросов, и постгрес пытается построить оптимальный план выполнения,но у него это не получается. По идее можно вставлять set enable_nestloop false непосредственно в запрос, но у 1С на такую мелочь, видимо времени нету... Истинные Postgres men  при виде подобного (enable_nestloop=off) недовольно морщатся...На sql.ru были обсуждения. В принципе, отключать постоянно оптимизацию чего либо действительно нехорошо.

v8: На какой СУБД работает ваша 1С8?
Тут про это есть.

(37)Спасибо) Ну я примерно про это догонял. У нас в УТ у оптовиков Отчет "Анализ цен" с enable_nestloop=off выполняется 5 сек, иначе 30 минут. Волнует вопрос, как это отразится на выполнении других, более мелких запросах? Пока поставили enable_nestloop=off, отдадим на тесты подопытным. И с блокировками как дела у тебя при выключенном параметре? "Управление торговлей", редакция 10.3 (10.3.13.2) Сконвертировали на 8.2, работает в автоматическом режиме управления блокировкой данных.

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

(40) угу. Но тем не менее не понятно что за блеать с сервером... На скл 6 сас-винтов (15к) в 10-ом рейде, капец

+(41) многочисленные тесты показали, провали (огромный по-сути) идет со стороны сети. Сеть "послушали", все норм. Вот и думай после этого о разнесении сервера 1с и sql на разные машины (хоть и производительные)... Короче буду дальше "играться" с сеткой, может чего нарою...

+(42) *провали = провалы

(40)Машина одна. Тут именно в оптимизации дело, у нас во всяком случае.
(41)Ну хоть кому то еще "помог" этот тест)

(42) Может попробовать оба сервера через вторые сетевые интерфейсы(если есть) в отдельный коммутатор подключить, с отдельными IP адресами? А SQL сервер вообще в общую сеть не включать, клиентам же только нужен сервер 1С? Интересно, получится так?

(45) конечно получится, так и планирую в ближ. выходные поступить. Вопрос лишь в том, как сильно это изменит расклад

У меня тоже косяк с производительностью по этому тесту(

(39) С блокировками, вроде, проблем нет, замечено ничего такого не было.