dbf vs sql - производельность

В этом разделе обсуждаются серверы для работы с 1С

Модераторы: Trinity admin`s, Free-lance moderator`s

Ответить
edo
Advanced member
Сообщения: 123
Зарегистрирован: 14 фев 2006, 02:40
Откуда: пенза

dbf vs sql - производельность

Сообщение edo » 26 фев 2006, 16:13

взяли небольшую базу (4 гига), загрузили в sql, запустили перепроведение. точные измеренеия проводить желание сразу отпало - sql медленнее где-то на порядок (то бишь в 10 раз).

перепроведение было выбрано по простой причине: для нас сейчас больная тема - транзакции, внутри транзакций то же самое проведение документов и идет (нам его требуется максимально ускорить).


вопрос - это нормальный результат или руки кривые?

Аватара пользователя
Stranger03
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 12979
Зарегистрирован: 14 ноя 2003, 16:25
Откуда: СПб, Екатеринбург
Контактная информация:

Re: dbf vs sql - производельность

Сообщение Stranger03 » 26 фев 2006, 16:47

edo писал(а):взяли небольшую базу (4 гига), загрузили в sql, запустили перепроведение. точные измеренеия проводить желание сразу отпало - sql медленнее где-то на порядок (то бишь в 10 раз)
SQL медленнее. Она предназначена прежде всего для целостности. В зависимости от конфигурации системы SQL может быть чуть медленнее, но никак не в разы. Если вы напишите хотя бы приложение, конфигурацию сервера, дисковую систему, распределение данных по дисковым системам. Плюс скажете настраивали ли SQL или по умолчанию, а может еще запустите счетчики, то вам может быть и ответят, в чем вы не правы.
Пока имхо вы где-то не правы.

edo
Advanced member
Сообщения: 123
Зарегистрирован: 14 фев 2006, 02:40
Откуда: пенза

Сообщение edo » 26 фев 2006, 16:56

приложение - 1с 7.7 с самописной конфигурацией

сервер - 2xXeon 2.6, 2Gb, 2xSCSI 15k в raid 0 на lsi 320-2.
1с крутилась на другом компьютере. sql не настраивали

Аватара пользователя
Stranger03
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 12979
Зарегистрирован: 14 ноя 2003, 16:25
Откуда: СПб, Екатеринбург
Контактная информация:

Сообщение Stranger03 » 26 фев 2006, 17:38

edo писал(а):сервер - 2xXeon 2.6, 2Gb, 2xSCSI 15k в raid 0 на lsi 320-2.
Не совсем понял, РАИД 0? И 320-2 контроллер на двух винтах? Это еще зачем?

edo
Advanced member
Сообщения: 123
Зарегистрирован: 14 фев 2006, 02:40
Откуда: пенза

Сообщение edo » 26 фев 2006, 17:46

дык не новый же сервер для тестов покупать? ;)
места свободного на raid 0 больше всего было.

Аватара пользователя
gs
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16650
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 26 фев 2006, 18:05

Завтра Шац придет - поговорите по поводу тюнинга сиквела под Нуралиева :)

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 27 фев 2006, 14:47

Самое смешное - упор у Вас был в сеть или производительность писюка, на котором крутилась 1С :D .Фишка в том, что по сети клиент тянет к себе все - что с SQL, что с dbf - и SQL действительно по определению медленнее. Особенно - когда его используют как тупое хранилище :) Именно из-за этого с 1С7.7 часто используются терминальные решения.
А RAID0 - никогда не используйте для хранения данных.
Самая забавная картина по этому поводу - в гугле: поищите по словам "Помогите" и RAID0 :gigi:

NetIq
Junior member
Сообщения: 19
Зарегистрирован: 17 мар 2003, 22:50

Сообщение NetIq » 27 фев 2006, 18:41

Возможно, вам поможет решение от SoftPoint (внешняя компонента "Ускорение массового проведения документов").
По оценкам наших программеров 1С, после "внедрежа" данной штуковины, скорость перепроведения (именно массового перепроведения документов) прошедшего месяца увеличилась ~ в 3 раза.

Аватара пользователя
Stranger03
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 12979
Зарегистрирован: 14 ноя 2003, 16:25
Откуда: СПб, Екатеринбург
Контактная информация:

Сообщение Stranger03 » 01 мар 2006, 19:03

И еще самая забавная штука, что за словом SQL 1C 7.7 скрывается так называемые портированные DBF с их плоской структурой. Единственный момент, который позволяет SQL, это увеличить надежность записываемых данных за счет транзакций записи этих самых данных. В этом случае надобность в переиндексации отпадает. А в скорости здесь не выиграть, тем более на 7.7

talb
Junior member
Сообщения: 10
Зарегистрирован: 02 мар 2006, 10:16
Контактная информация:

Сообщение talb » 02 мар 2006, 10:21

Фишка в том, что по сети клиент тянет к себе все - что с SQL, что с dbf - и SQL действительно по определению медленнее.
Для решения этой проблемы можно воспользоваться внешней компонентой 1с++ (http://www.1cpp.ru), которая позволяет получать с SQL сервера то, что нужно. В нашем случае выборка данных и соответственно проведение ускорилось до 10-15 раз.
PS при условии того, что у нас SQL сервер отдельно, терминал отдельно.

edo
Advanced member
Сообщения: 123
Зарегистрирован: 14 фев 2006, 02:40
Откуда: пенза

Сообщение edo » 02 мар 2006, 10:43

реально индексы в 1с портятся не так уж и часто (при сетевой работе), при работе в терминале - фактически никогда.

а запрос на переиндексацию означает просто, что какой-то процесс 1с завершился не совсем нормально и это отражено в базе. грубо говоря аналогично поступает винда на fat-разделах - после некорректного завершения работы она запускает проверку файловой системы (в случае ntfs же происходит откат журнала - неожиданная ассоциация с sql).

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

подводя итог - довод о отсутствии переиндексации в sql достаточно спорен. с другой стороны sql имеет неспоримые плюсы - возможность снимать бэкапы с рабочей базы, теоретически большую надежность, быстрые отчеты и т.д.

но вот наша проблема - ступор 1с при массовом проведении документов, и sql её не только не решит, а только усугубит.
объясняю - sql не отменяет транзакцию как блокировку всего и вся на запись и при этом увеличивает продолжительность проведения документов (то есть продолжительность транзакции).

2a_shats: я толком не понял во что всё уперлось. сеть и процессор клиента нагружены очень слабо, дисковая сервера тоже

2NetIq: про тот баг я внимательно читал - он проявляется как постепенное замедление проведенния документов. у меня же sql начинает перепроводить документы сущесвенно медленнее dbf. падает ли ещё скорость перепроведения в дальнейшем - не проверял и желания такого не имею

Аватара пользователя
Stranger03
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 12979
Зарегистрирован: 14 ноя 2003, 16:25
Откуда: СПб, Екатеринбург
Контактная информация:

Сообщение Stranger03 » 02 мар 2006, 17:29

edo писал(а):но вот наша проблема - ступор 1с при массовом проведении документов, и sql её не только не решит, а только усугубит.
Лет 5-6 назад я долго пытался понять, чем занимается сервер и клиент 1С в сети. Отслеживал сетевые пакеты, снимал статистику по процессору, памяти, дискам на сервере. Речь тогда шла о 7.7 билд 014 по сети. Честно говоря причину найти не удалось. Видимо в момент проведения документов 1С пытается по сети блокировать базу целиком, ей это долго не удается. Решение простое - терминалка. На базах до пары гигов идеальна.

Аватара пользователя
Stranger03
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 12979
Зарегистрирован: 14 ноя 2003, 16:25
Откуда: СПб, Екатеринбург
Контактная информация:

Сообщение Stranger03 » 02 мар 2006, 17:35

Еще где-то здесь коллеги писали, что в момент массового проведения документов 1С по сети пытается захватить базу целиком. Скуль в этом бы помог, поскольку он блокирует только запись в момент проведения транзакции.

edo
Advanced member
Сообщения: 123
Зарегистрирован: 14 фев 2006, 02:40
Откуда: пенза

Сообщение edo » 02 мар 2006, 18:13

помог бы - но 1с реализует свои собственные блокировки и на время транзакции все остальные ждут, независимо sql или dbf

Ответить

Вернуться в «Конфигурации сервера для 1С»

Кто сейчас на конференции

Сейчас этот форум просматривают: Google [Bot] и 24 гостя