Потребовалось сделать сервер 1С для чего была выбрана связка OracleLinux 6.1 + 1C82 (8.2.14.519) + Postgres 9.0.4.Собрал следующее железо для тестов:
MB: Asus P5
CPU : Intel(R) Pentium(R) D CPU 3.20GHz 2 ядра
MEM : 8G
HDD : 1x160G 7200 (старый нового не нашлось)hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 2670 MB in 2.00 seconds = 1335.62 MB/sec
Timing buffered disk reads: 220 MB in 3.00 seconds = 73.30 MB/secПри установке выделил под SWAP 10G, остальное под корень, получилось что-то вроде:
/dev/sda1 * 1 18152 145803264 83 Linux
/dev/sda2 18152 19458 10484736 82 Linux своп / Solarisставил все без LVM, разбивка руками. Выбрал минимальную установку
Прицепил RPM-репозитории:
cd /etc/yum.repos.d
touch public-yum-ol6.repoдобавил в файл public-yum-ol6.repo:
[ol6_ga_base]
name=Oracle Linux 6 GA - $basearch - base
baseurl=http://public-yum.oracle.com/repo/OracleLinux/OL6/0/base/$basearch/
gpgkey=http://public-yum.oracle.com/RPM-GPG-KEY-oracle-ol6
gpgcheck=1
enabled=1[ol6_u1_base]
name=Oracle Linux 6 U1 - $basearch - base
baseurl=http://public-yum.oracle.com/repo/OracleLinux/OL6/1/base/$basearch/
gpgkey=http://public-yum.oracle.com/RPM-GPG-KEY-oracle-ol6
gpgcheck=1
enabled=1затем все как обычно
yum update
итак что видим ....
если верить описанию система очень быстрая, некоторые прогнозируют прирост аж 110 процентов.
смотрим что есть по дефолтуcat /etc/sysctl.conf
# Kernel sysctl configuration file for Red Hat Linux
# Controls IP packet forwarding
net.ipv4.ip_forward = 0# Controls source route verification
net.ipv4.conf.default.rp_filter = 1# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 1# Disable netfilter on bridges.
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0# Controls the maximum size of a message, in bytes
kernel.msgmnb = 65536# Controls the default maxmimum size of a mesage queue
kernel.msgmax = 65536# Controls the maximum shared segment size, in bytes
kernel.shmmax = 68719476736# Controls the maximum number of shared memory segments, in pages
kernel.shmall = 4294967296
vm.overcommit_memory=2неплохо
добавим на всякий случайkernel.panic=5
kernel.panic_on_oops=5
kernel.panic_on_io_nmi=5
kernel.panic_on_unrecovered_nmi=5отключим все ненужное .... взламывать сервер некому, он будет сугубо локальным.
chkconfig ip6tables off
chkconfig iptables off
chkconfig netfs off
chkconfig postfix off
chkconfig saslauthd offзатем отключим SELinux, так как с ним не работает 1C.
vi /etc/selinux/config
SELINUX=disabled
и reboot
Приступим к настройке 1C и PostgreSQL. Прочитал статью http://www.alsigned.ru/?p=1129 про установку 1С 8.2 в связке с Postgresql 9.0. Сделал все как в статье, единственно подменил в конфигурации PostgreSQL 9.0.4 и патчи взял для версии 9.0.3 (http://v8.1c.ru/overview/postgres_patches_notes.htm).
Краткое изложение процесса:
Загружаем необходимые пакеты:
yum install rpm-build gcc make glibc-devel bison flex python-devel tcl-devel readline-devel \
zlib-devel openssl-devel krb5-devel e2fsprogs-devel gettext pam-devel openldap-devel icu libicu libicu-develПатчим PostgreSQL
wget http://v8.1c.ru/overview/postgresql_patches/9-0-4/postgresql...
rpm -i postgresql-9.0.4-1.1C.src.rpmВ файле /usr/lib/rpm/macros в параметре %_default_patch_fuzz заменяем 0 на 2.
В файле /root/rpmbuild/SOURCES/postgresql.init прописываем:PGENGINE=/usr/pgsql/bin
PGDATA=/var/lib/pgsql/data
PGLOG=/var/lib/pgsql/pgstartup.logВ spec-файле /root/rpmbuild/SPECS/postgresql-9.0-4C.spec меняем postgresql-9.0 на postgresql, получится примерно так:
525 chkconfig --add postgresql
530 sbin/service postgresql condstop >/dev/null 2>&1
531 chkconfig --del postgresql
537 /sbin/service postgresql condrestart >/dev/null 2>&1Собираем пакет с пропатченным PostgreSQL:
rpmbuild -ba --define 'runselftest 0' /root/rpmbuild/SPECS/postgresql-9.0-4C.specУстанавливаем пакет:
rpm -i /root/rpmbuild/RPMS/x86_64/*.rpmИнициализируем БД:
su postgres
/usr/pgsql/bin/initdb -D /var/lib/pgsql/data --locale=ru_RU.UTF-8Запускаем postgresql:
service postgresql start
Устанавливаем 1С:
Указываем имя хоста в /etc/hosts (имя должно совпадать с именем HOSTNAME, указанным в файле /etc/sysconfig/network):127.0.0.1 localhost 1csrv 1csrv.mydomain.local
192.168.1.1 1csrv 1csrv.mydomain.local
Устанавливаем пакеты с 1С:rpm -i 1C_Enterprise82-common-8.2.13-205.x86_64.rpm 1C_Enterprise82-server-8.2.13-205.x86_64.rpm \
1C_Enterprise82-ws-8.2.13-205.x86_64.rpm 1C_Enterprise82-common-nls-8.2.13-205.x86_64.rpm \
1C_Enterprise82-server-nls-8.2.13-205.x86_64.rpm 1C_Enterprise82-ws-nls-8.2.13-205.x86_64.rpmдалее активируем сервисы 1c и postgresql:
chkconfig srv1cv82 on
chkconfig postgresql onВ .bash_profile правим "PGDATA=/var/lib/pgsql9/data" на "PGDATA=/var/lib/pgsql/data".
Далее запустил 1С-клиента, создал базу TEST и запустил тест Гилева (gilev.ru)
...ждал минут 20 !!!! набрал 9.1 !!! балов явно мало для комфортной работы. Гилев рекомендует включить блокировки вручную .... что и делаем через конфигуратор
снова тест ..... уже 14 баллов.Пробуем оптимизировать postgresql.conf:
shared_buffers = 1024MB # min 128kB
work_mem = 400MB # min 64kB
maintenance_work_mem = 2048MB # min 1MB
fsync = off # turns forced synchronization on or off
wal_sync_method = fdatasync # the default is the first option
commit_delay = 50 # range 0-100000, in microseconds
commit_siblings = 7 # range 1-1000
cpu_tuple_cost = 0.001 # same scale as above
cpu_index_tuple_cost = 0.0005 # same scale as above
effective_cache_size = 4096MBдалее
/etc/init.d/postgresql restart
/etc/init.d/srv1cv82 restartСледующее тестирование показало 20.4 баллов.... неплохой результат.
Поставил две конфигурации кадрыКОРП + бухгалтерияКОПРП. В конфигураторе сменил блокировки на управляемый режим блокировок.Написал скрипт для чистки логов и бекапа БД и поместил его в cron:
#!/bin/bash
set +x
/bin/rm -rf /backups/1c/*.log
/bin/touch /backups/1c/1c8_bkp.logBKPDIR=/backups/1c
TIME=`date +%d-%m-%Y_%H:%M:%S` # год,месяц,день,часы,минуты
DATE_ARC=`date +%d%m%Y`LOG=/backups/1c/1c8_bkp.log
dl() {
$* >> $LOG 2>&1
}dl echo $TIME
dl /etc/init.d/srv1cv82 stop
dl /bin/sleep 10
/bin/find /backups/1c -type f -mtime +1 -print | /usr/bin/xargs /bin/rm -f
/bin/find /var/lib/pgsql/data/pg_log/ -type f -mtime +1 -print | /usr/bin/xargs /bin/rm -f/usr/pgsql/bin/pg_dump -U postgres -Fc -Z9 -c -f /backups/1c/buh.$DATE_ARC.sql buh
/usr/pgsql/bin/pg_dump -U postgres -Fc -Z9 -c -f /backups/1c/hrm.$DATE_ARC.sql hrm
/usr/pgsql/bin/pg_dump -U postgres -Fc -Z9 -c -f /backups/1c/test.$DATE_ARC.sql testdl echo $TIME
dl /etc/init.d/srv1cv82 startВот пожалуй и все
URL: http://www.alsigned.ru/?p=1129
Обсуждается: https://www.opennet.ru/tips/info/2621.shtml
только один вопрос?
- Почему OracleLinux???
ага, мне тоже интересно... судя по статье - он не лицензирован, тогда смысл в нем? апдейты ставить нельзя...
он бесплатный. апдейты ставятся
> он бесплатный. апдейты ставятсяда, он бесплатный, только вот апдейты стоят денег
Да это всё приминимо к любому клону шапки, на CentOS или Fedora отличаться не будит.
Автор видимо голословно поверил, но все таки решил проверить.
>если верить описанию система очень быстрая, некоторые прогнозируют прирост аж 110 процентов.
Очень доволен OracleLinux
Сделан неплохо но одно огорчает мало пакетов и иногда что нужно приходится собирать руками !!!
> vi /etc/selinux/config
> SELINUX=disabledНа этом закончил читать. Руки за это надо отрывать, что в 2011 году кто-то так с selinux поступает.
1С что, системный демон чтобы быть ограниченным selinux? Наверняка там все дело в паре алертов, косвенно связанных с базой или чем-то подобным, выключаемых установкой одного seboolean'а.
Да и утверждение, что мол нелицензионный oracle linux обеспечивает прирост быстродействия 110% и тд.. Замечательный аргумент, чтобы лишаться обновлений и т.д.. Нет чтобы поставить SL или что-то подобное, где все работает..
>> vi /etc/selinux/config
>> SELINUX=disabled
> На этом закончил читать. Руки за это надо отрывать, что в 2011
> году кто-то так с selinux поступает.
> 1С что, системный демон чтобы быть ограниченным selinux? Наверняка там все дело
> в паре алертов, косвенно связанных с базой или чем-то подобным, выключаемых
> установкой одного seboolean'а.
> Да и утверждение, что мол нелицензионный oracle linux обеспечивает прирост быстродействия
> 110% и тд.. Замечательный аргумент, чтобы лишаться обновлений и т.д.. Нет
> чтобы поставить SL или что-то подобное, где все работает..Может быть но для теста SEL не нужен
> vi /etc/selinux/config
> SELINUX=disabledНа этом закончил читать. Руки за это надо отрывать, что в 2011 году кто-то так с selinux поступает.
Руки надо отрывать за такие посты. Если в безопасности на конкретном сервере нет необходимости, зачем держать то что тебе не нужно ?
На сервере в безопасности необходима в первую очередь. Так что с selinux статья выглядела бы действительно пристойно.
> Руки за это надо отрывать, что в 2011 году кто-то так с selinux поступает.Толку то с вашего selinux. Гемора создает много, а в случае дыр в ядре - выносится первым же сплойтом первым делом. А без дыр как-то и без него неплохо, знаете ли. В общем хрень нужная только потому что у некоторых бюрократов по уставу положено MAC и все тут. Вынь да полож, или всякие АНБ и прочие квадратноголовые просто не пустят это к себе в системы. У них же регламент доступа к информации, типа.
> fsync = offНу теперь то Вашим данным точно каюк.
Это тест !!! И данные не критичны
> Это тест !!! И данные не критичныhttp://gilev.ru/1c/tpc/tpc82.rar
Вот сам тест
берем файлик tpc82.dt
Это слив, без fsync такого прироста производительности не будет.
Старые конфигурации с табличными блокировками портят кровь.:/ Сейчас используем Postgres 8.4 на CentOS 5.6. Размер кластера почти 500gb.
В целом довольны. Программеры обещают переписать блокировки.
Интереса ради запустил этот тест tpc82, показало 20 с копейками.
> Размер кластера почти 500gb.интересно.
а подскажите пожалуйста, у нас сервер приложений и сервер БД на разных машинах, так вот на сервере выделенном под БД используется только один процессор, точнее одно ядро! Вы с такой проблемой не сталкивались? куда копать?
>> Размер кластера почти 500gb.
> интересно.
> а подскажите пожалуйста, у нас сервер приложений и сервер БД на разных
> машинах, так вот на сервере выделенном под БД используется только один
> процессор, точнее одно ядро! Вы с такой проблемой не сталкивались? куда
> копать?В смысле? По описанию похоже на то, что просто PostgreSQL на одно соединение больше одного процессора не использует. Так это нормально, архитектура такая. Делайте больше рабочих процессов на сервере приложений, убедитесь, что 1С открывает несколько соединений, под нагрузкой вполне себе будет использовать все.
> Делайте больше рабочих процессов на сервере приложений, убедитесь, что 1С открывает
> несколько соединений, под нагрузкой вполне себе будет использовать все.прошу прощения, я ещё не успел ознакомится с документацией, если не сложно напишите как это сделать?
>> Делайте больше рабочих процессов на сервере приложений, убедитесь, что 1С открывает
>> несколько соединений, под нагрузкой вполне себе будет использовать все.
> прошу прощения, я ещё не успел ознакомится с документацией, если не сложно
> напишите как это сделать?В консоли кластера 1С, надо создать еще рабочих процессов. Но если клиентов мало, то не надо, будет бестолку. Да и исходных данных нет, сколько клиентов, как работают, какая конфигурация, размер базы и характеристики сервера.
Скорее всего нагрузки нет, чтобы все ядра загрузить.
> В консоли кластера 1С, надо создать еще рабочих процессов. Но если клиентов
> мало, то не надо, будет бестолку. Да и исходных данных нет,
> сколько клиентов, как работают, какая конфигурация, размер базы и характеристики сервера.
> Скорее всего нагрузки нет, чтобы все ядра загрузить.выяснил по подробней. в общем проблема проявляется при закрытии месяца. т.е. клиент один и увеличение кол-ва рабочих процессов не помогает.
Конфигурационный файл: по умолчанию, пробовали изменять множество настроек. Размер БД: 25Гб, Железо 2 x Intel(R) Xeon(R) CPU E5520, 2.27GHz (16 cores), 2 HDD x 500 Gb (RAID1).
> выяснил по подробней. в общем проблема проявляется при закрытии месяца. т.е. клиент
> один и увеличение кол-ва рабочих процессов не помогает.
> Конфигурационный файл: по умолчанию, пробовали изменять множество настроек. Размер БД:
> 25Гб, Железо 2 x Intel(R) Xeon(R) CPU E5520, 2.27GHz (16 cores),
> 2 HDD x 500 Gb (RAID1).Базка-то махонькая. Видимо то самое закрытие месяца неудачный для постгреса запрос. Неоптимальный, скажем так. Найдите кого-нибудь, кто посмотрит что именно делается и во что уперлись, в процессор, или в диски, например. Похоже на мутный и долгий запрос, с кучей вложенных.
> Базка-то махонькая. Видимо то самое закрытие месяца неудачный для постгреса запрос. Неоптимальный,
> скажем так. Найдите кого-нибудь, кто посмотрит что именно делается и во
> что уперлись, в процессор, или в диски, например. Похоже на мутный
> и долгий запрос, с кучей вложенных.смотрели уже:
в диски вообще не упираемся (смотрел vmstat/top iowait), а проц юзается только один(особенно хорошо видно в htop'е было). Т.е. 100% дело в использовании CPU постгресом.
в официальной тех. поддержке 1С развели руками...
> смотрели уже:
> в диски вообще не упираемся (смотрел vmstat/top iowait), а проц юзается только
> один(особенно хорошо видно в htop'е было). Т.е. 100% дело в использовании
> CPU постгресом.
> в официальной тех. поддержке 1С развели руками...Ну похоже запрос длинный. Он вообще завершается за разумное время?
Включите log_duration_statement, track_activities, c track_activities_query_size=102400.
Дальше либо смотрите в pg_stat_activities, либо в лог, если он туда запишется, что там за запрос, выковыривайте, план выполнения курите и все такое :)
> Дальше либо смотрите в pg_stat_activities, либо в лог, если он туда запишется,
> что там за запрос, выковыривайте, план выполнения курите и все такое
> :)странно, я думал у всех такая проблема, но раз вы так говорите, то стоит посмотреть explain.. (не думал что нужно это делать в случаях с 1С, да и знаний/опыта на PG уже не хватает)
>> Дальше либо смотрите в pg_stat_activities, либо в лог, если он туда запишется,
>> что там за запрос, выковыривайте, план выполнения курите и все такое
>> :)
> странно, я думал у всех такая проблема, но раз вы так говорите,
> то стоит посмотреть explain.. (не думал что нужно это делать в
> случаях с 1С, да и знаний/опыта на PG уже не хватает)Еще как нужно. Мы когда переходили с MS SQL на Postgres первое время в планы выполнения пялились постоянно. Потому как по другому там никак. Индексы построить и конфиг покрутить это все конечно хорошо, но если запрос в принципе мертвый и не выполнится за разумное время - тут только переписывать.
У нас правда много конфигураций досточно старых еще под 8.1 писанных. Там много отчетов без использования временных таблиц, строго на вложенных запросах.
Грамотный 1С-программер нужен обязательно.
У нас сейчас баз с десяток на одном сервере, из них самая большая без индексов под 200G размером и ничего, работаем, не жалуемся.
Кстати, те кто данную статью прочтут - не делайте fsync = off, если не уверены на 100% что понимаете что это.
Да и вообще не правьте конфиги в точности как автор.:)
> Кстати, те кто данную статью прочтут - не делайте fsync = off,
> если не уверены на 100% что понимаете что это.
> Да и вообще не правьте конфиги в точности как автор.:)Проверил все планировщики
open_datasync 21.75
fdatasync 21.65
fsync 21.28
fsync_writethrough не запустился
open_sync 21.37оставил open_datasync
по поводу fsync = off говорю же это просто тест !!!!
Сейчас дождусь аппаратного райда и fsync = off будет включена по дефолту
сейчас у меня 4 базы дампы где то по 300M полет пока нормальный
> оставил open_datasync
> по поводу fsync = off говорю же это просто тест !!!!
> Сейчас дождусь аппаратного райда и fsync = off будет включена по дефолтуТест с fsync = off бесполезен. И разница между fsync = off и fsync = on но рейде с батарейкой есть и ощутимая.
> сейчас у меня 4 базы дампы где то по 300M полет пока
> нормальныйБудет и дальше нормальный. На значительно больших размерах тоже можно работать. Если программисты, рисовавшие конфигурацию, не очень криворукие.
> Будет и дальше нормальный. На значительно больших размерах тоже можно работать. Если
> программисты, рисовавшие конфигурацию, не очень криворукие.конфигурации все стандартные сам ничего не пишу .... т.к. нет в этом необходимости
>> Будет и дальше нормальный. На значительно больших размерах тоже можно работать. Если
>> программисты, рисовавшие конфигурацию, не очень криворукие.
> конфигурации все стандартные сам ничего не пишу .... т.к. нет в этом
> необходимостиУ нас грабли только табличными блокировками и с запросами с типовых конфигураций. Некоторые отчеты активно используют вложенные запросы, на больших объемах начинаются веселухи, навроде 3 дня выполнения отчета.
Перешел на платформу 8.2.14.533 и поставил
wal_sync_method = open_sync
Набрал 20.92 !!!
:)
У кого есть доступ на сервер 1С ???? может документацию ктонить скачает и рекомендации по настройке сервера postgres там есть статьи но доступа нет у меня
Хотел бы уточнить на счет теста Гилева:
- какие экстремумы (максимум, минимум) в баллах получают при тестировании примерно на таком железе?
- сколько баллов получает 1С примерно на такой же конфигурацией с использованием MSSQL?
> Хотел бы уточнить на счет теста Гилева:
> - какие экстремумы (максимум, минимум) в баллах получают при тестировании примерно
> на таком железе?
> - сколько баллов получает 1С примерно на такой же конфигурацией с
> использованием MSSQL?К сожалению тест под MSSQL не проводился также как и под Oracle и DB2
Но у кого есть тесты положите плиз будет интересно
также интересны тесты с другими файловыми системами Btrfs например или ext3. у меня MySQL на Btrfs крутится пока нет проблем
по нашим тестам тюненная постре медленне МСсиквела 2005 в "гилёвотесте" на 20%, не тюненная 10%, а файловая минимум в 4 раза быстрее, чем постгресина тюненная. Что удивительно, если тесты проводить в виртуалке, то результаты ваще не однозачные, ибо по результатам, постгре в линупсе (центос отsysctlенный, постре тож тюненный) не дотягивает до своего собрата на винде, тесты проводились и на РАМ диске.
> по нашим тестам тюненная постре медленне МСсиквела 2005 в "гилёвотесте" на 20%, не тюненная 10%Продолжайте и дальше тюнить в том же духе. )) Виртуалка поди M$овская?)
> по нашим тестам тюненная постре медленне МСсиквела 2005 в "гилёвотесте" на 20%,
> не тюненная 10%, а файловая минимум в 4 раза быстрее, чем
> постгресина тюненная. Что удивительно, если тесты проводить в виртуалке, то результаты
> ваще не однозачные, ибо по результатам, постгре в линупсе (центос отsysctlенный,
> постре тож тюненный) не дотягивает до своего собрата на винде, тесты
> проводились и на РАМ диске.А pgbench что показывает? Там по крайней мере понятно что делается. В тесте гилева только "попугаи" на выходе. Надо смотреть внутрь, отчего так.
Вот что нашел на
http://www.westnet.com/~gsmith/content/postgresql/pgbench.htm#!/bin/sh
DB=alex
tottrans=10000
c=1
t=`expr $tottrans / $c`
echo Cleaning up database $DB
psql -c 'truncate table history' $DB
psql -c 'vacuum' $DB
psql -c 'vacuum full' $DB
psql -c 'vacuum analyze' $DB
psql -c 'checkpoint' $DB
echo $t transactions for each of $c concurrent users... 1>&2
/usr/pgsql/bin/pgbench -l -N -n -t $t -c $c $DB &
p=$!
wait $p
mv pgbench_log.${p} pgbench.log
cat pgbench.log | cut -f 3 -d " " | sort -n | tailзашел как
su - postgres
запустил
вот результатCleaning up database alex
ERROR: relation "history" does not exist
VACUUM
VACUUM
VACUUM
CHECKPOINT
10000 transactions for each of 1 concurrent users...
transaction type: Update only pgbench_accounts
scaling factor: 1
query mode: simple
number of clients: 1
number of threads: 1
number of transactions per client: 10000
number of transactions actually processed: 10000/10000
tps = 1708.830347 (including connections establishing)
tps = 1709.843054 (excluding connections establishing)
1039
1044
1092
1363
1477
1725
3119
3593
4846
11795при с=10
Cleaning up database alex
ERROR: relation "history" does not exist
VACUUM
VACUUM
VACUUM
CHECKPOINT
1000 transactions for each of 10 concurrent users...
transaction type: Update only pgbench_accounts
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 1000
number of transactions actually processed: 10000/10000
tps = 2419.187642 (including connections establishing)
tps = 2439.170740 (excluding connections establishing)
17329
17489
17886
17899
17913
17953
18222
18224
24267
26417
> Вот что нашел на
> http://www.westnet.com/~gsmith/content/postgresql/pgbench.htmЭто с fsync = off я так понимаю?
>> Вот что нашел на
>> http://www.westnet.com/~gsmith/content/postgresql/pgbench.htm
> Это с fsync = off я так понимаю?Да
вот еще-bash-4.1$ /usr/pgsql/bin/pgbench -c 10 -t 3000 alex
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 3000
number of transactions actually processed: 30000/30000
tps = 1014.325899 (including connections establishing)
tps = 1015.464440 (excluding connections establishing)-bash-4.1$ /usr/pgsql/bin/pgbench -c 50 -t 3000 alex
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 50
number of threads: 1
number of transactions per client: 3000
number of transactions actually processed: 150000/150000
tps = 954.714991 (including connections establishing)
tps = 955.709272 (excluding connections establishing)
>>> Вот что нашел на
>>> http://www.westnet.com/~gsmith/content/postgresql/pgbench.htm
>> Это с fsync = off я так понимаю?
> Да
> вот ещеЭто бесполезный бенч. На живой базе с fsync = off вы же работать не будете.
> Это бесполезный бенч. На живой базе с fsync = off вы же
> работать не будете.буду .... купил райд + винты сейчас все цепляю и буду тестировать
>> Это бесполезный бенч. На живой базе с fsync = off вы же
>> работать не будете.
> буду .... купил райд + винты сейчас все цепляю и буду тестироватьВы уверены, что понимаете, что делает fsync = off?
как получить 35 баллов ???? кто райды использует например 5-й или 10-й ????
с fsync = on/usr/pgsql/bin/pgbench -i alex
NOTICE: table "pgbench_branches" does not exist, skipping
NOTICE: table "pgbench_tellers" does not exist, skipping
NOTICE: table "pgbench_accounts" does not exist, skipping
NOTICE: table "pgbench_history" does not exist, skipping
creating tables...
10000 tuples done.
20000 tuples done.
30000 tuples done.
40000 tuples done.
50000 tuples done.
60000 tuples done.
70000 tuples done.
80000 tuples done.
90000 tuples done.
100000 tuples done.
set primary key...
NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "pgbench_branches_pkey" for table "pgbench_branches"
NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "pgbench_tellers_pkey" for table "pgbench_tellers"
NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "pgbench_accounts_pkey" for table "pgbench_accounts"
vacuum...done.-bash-4.1$ /usr/pgsql/bin/pgbench -c 100 -t 300 alex
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 100
number of threads: 1
number of transactions per client: 300
number of transactions actually processed: 30000/30000
tps = 111.247465 (including connections establishing)
tps = 111.381112 (excluding connections establishing)Это без райда ......
поставил
synchronous_commit = off-bash-4.1$ /usr/pgsql/bin/pgbench -c 100 -t 300 alex
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 100
number of threads: 1
number of transactions per client: 300
number of transactions actually processed: 30000/30000
tps = 444.281640 (including connections establishing)
tps = 446.328705 (excluding connections establishing)установил
wal_buffers = 1024kB/usr/pgsql/bin/pgbench -c 100 -t 300 alex
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 100
number of threads: 1
number of transactions per client: 300
number of transactions actually processed: 30000/30000
tps = 673.658917 (including connections establishing)
tps = 678.406905 (excluding connections establishing)
вопрос кто юзает PostgreSQL@Etersoft ????
какие впечатления ..... и если можно то выложите тесты pgbench и гилева
> вопрос кто юзает PostgreSQL@Etersoft ????
> какие впечатления ..... и если можно то выложите тесты pgbench и гилеваХорошие впечатления. Да это на самом деле просто уже готовая сборка, с парой фиксов.
Тесты не выложу, в отпуске :), на тесте gilev помнится было 20 с копейками.
перенес каталоги
pg_clog , pg_xlog, pg_log на другой дисксоздал на них символические ссылки
/usr/pgsql/bin/pgbench -c 100 -t 300 alex
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 100
number of threads: 1
number of transactions per client: 300
number of transactions actually processed: 30000/30000
tps = 687.226120 (including connections establishing)
tps = 692.270491 (excluding connections establishing)гилев 21.3 показал ......
интересно какое надо железо чтоб 60 было !!!!!
Чтобы в лог не валилось много ошибок типа
WARNING: nonstandard use of \\ in a string literal at character 5929
HINT: Use the escape string syntax for backslashes, e.g., E'\\'.
нужно добавить
escape_string_warning = off
ну вот собрал RAID 10
4 винта по 250 WD2503ABYX RAID FastTrak TX4310-bash-4.1$ /usr/pgsql/bin/pgbench -i alex
NOTICE: table "pgbench_branches" does not exist, skipping
NOTICE: table "pgbench_tellers" does not exist, skipping
NOTICE: table "pgbench_accounts" does not exist, skipping
NOTICE: table "pgbench_history" does not exist, skipping
creating tables...
10000 tuples done.
20000 tuples done.
30000 tuples done.
40000 tuples done.
50000 tuples done.
60000 tuples done.
70000 tuples done.
80000 tuples done.
90000 tuples done.
100000 tuples done.
set primary key...
NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "pgbench_branches_pkey" for table "pgbench_branches"
NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "pgbench_tellers_pkey" for table "pgbench_tellers"
NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "pgbench_accounts_pkey" for table "pgbench_accounts"
vacuum...done.-bash-4.1$ /usr/pgsql/bin/pgbench -c 10 -t 300 -j 10 alex
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 10
number of transactions per client: 300
number of transactions actually processed: 3000/3000
tps = 1603.210697 (including connections establishing)
tps = 1623.610501 (excluding connections establishing)Думал быстрее будет ....... в понедельник обновлю биос в райде + соберу дрова из исходников ......
> ну вот собрал RAID 10
> 4 винта по 250 WD2503ABYX RAID FastTrak TX4310Первая же дурная операция проведения, вешающая табличные блокировки, или неоптимальный отчет и плевать на все эти бенчмарки. Не майтесь дурью, лучше разберитесь с тем, как отчеты и запросы в самой 1С переписывать. Планы выполнения как смотреть и т.п.
Больше пользы в 100 раз.
Для любителей отключать fsync на сервере(таких как alexpn) приведу выдержку из доков:If this parameter is on, the PostgreSQL server will try to make sure that updates are physically written to disk, by issuing fsync() system calls or various equivalent methods (see wal_sync_method). This ensures that the database cluster can recover to a consistent state after an operating system or hardware crash.
While turning off fsync is often a performance benefit, this can result in unrecoverable data corruption in the event of a power failure or system crash. Thus it is only advisable to turn off fsync if you can easily recreate your entire database from external data.
Короче говоря, независимо от того raid у вас или нет и с батарейкой он или нет, то если данные вам дОроги, отключать fsync нельзя
для всех последних тестов со стоки fsync = ON Этот праметр НЕ ОТКЛЮЧАЛСЯ !!!!!ЦИТИРУЮ !!!!
Сообщение от alexpn (ok) on 09-Сен-11, 05:38
с fsync = onа то что програмеры в 1С заточены только под маздай дак это их проблема !!!!
в тесте с рейдомsynchronous_commit = on
fsync = on
единственное что сделано это весь /var перенесен на райд !
pg_log И прочие каталоги также остались на дополнительном диске !!!
Вопрос к автору: ссылка после "Патчим PostgreSQL" - "wget http://v8.1c.ru/overview/postgresql_patches/9-0-4/postgresql... - нерабочая. Откуда образовался postgresql-9.0.4-1.1C.src.rpm, поподробней можно, плиз?
> Вопрос к автору: ссылка после "Патчим PostgreSQL" - "wget http://v8.1c.ru/overview/postgresql_patches/9-0-4/postgresql...
> - нерабочая. Откуда образовался postgresql-9.0.4-1.1C.src.rpm, поподробней можно, плиз?Все просто !!!! качаем
http://v8.1c.ru/overview/postgresql_patches/9-0-3/postgresql...
затем качаем
http://wwwmaster.postgresql.org/download/mirrors-ftp/source/...
устанавливаем
rpm -Uvh postgresql-9.0.3-3.1C.src.rpmправим файлик
/root/rpmbuild/SPECS/postgresql-9.0-1C.spec
заменяем все на версию 9.0.4
строка 77
Version: 9.0.4
просто в прикол меняем строку 78
Release: 4.2C
правим остальные файлики как тут
http://www.alsigned.ru/?p=1129
не забываем про мягкие ссылки на библиотеки icuкопируем или переносим postgresql-9.0.4.tar.bz2 в
/root/rpmbuild/SOURCESдалее собираем
rpmbuild -ba --define 'runselftest 0' /root/rpmbuild/SPECS/postgresql-9.0-1C.spec
если все без ошибок
смотрим
ll /root/rpmbuild/RPMS/x86_64/или еще вариант ждем пока появится новый релиз скажем 9.0.5
вот тут
http://v8.1c.ru/overview/postgres_patches_notes.htm
либо юзаем готовый
http://v8.1c.ru/overview/postgresql_patches/9-0-3/postgresql...Извиняюсь за опечатки в статье
собрал с 9.0.5
единственное поправил ссылки
ln -s /usr/lib64/libicudata.so.42.1 /usr/local/lib64/libicudata.so.46
ln -s /usr/lib64/libicui18n.so.42.1 /usr/local/lib64/libicui18n.so.46
ln -s /usr/lib64/libicuuc.so.42.1 /usr/local/lib64/libicuuc.so.46в настоящий момент тестирую .....