База довольно не большая около 2ГБ, файловая. Пользователей около 40. Все это крутиться на 2*Xeon 2,4 4ГБ ОЗУ, RAID 0+1 SATA. База сильно переделанная ТИС 9.2 . Последне вермя база стала ощутимо тормозить.
Основные тормоза возникаю когда много пользователей начинают проводить документы. Т.е. видимо проблема с блокировками. И еще подбор ощутимо тормозит.
Задача: остаться на 7.7. При этом радикально избавиться от тормозов при условии, что в ближайшее время планируется подключение еще 20 пользователей.
Какие пути вижу:
1. Перейти на SQL и переписать особокритичные запросы на ToySQL.
2. Поменять дисковую подсистему на SAS.
Проблема в том, что покупка SQL сейчас дорогое удовольствие.
Прошу совета по альтернативным вариантам оптимизации?

Книга знаний: Изменение времени документов для выстраивания их на временной оси

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

А вот винты, это более лучший в данном случае вариант.

(2) Согласен, но SQL мне нужен именно для прямых запросов.

Книга знаний: Ускорение 1С:Предприятие 7.7
Там патч для скуля, который помогает 40 пользователям не конфликтовать при ожидании блокировок.

хм, 2 гб - крохотная база :)
может проще всех в терминал перекинуть?

(3) Если прямые запросы на чтение, то в результате будет все равно медленее, чем дбф (кроме отчетов), если прямые запросы на запись, тогда да имеет смысл переходить

(5) Да, я забыл написать, терминал уже используется 2003server.

(7) выставь всем юзерам период ожидания захвата таблиц 0 секунд

высказывания некоторых личностей про запросы на запись просто смехотворны

Проведение документов ускорить можно только ускорением обмена с дисками.
Как вариант, можно базу положить на RAM-диск (продаётся такая плата с микросхемами ОЗУ и резервным питанием от аккумулятора, которая работает как диск. Размер обычно 4 Гб - работает быстрее любого диска).
Что касается подбора, то надо смотреть на каком месте тормозит - может быть проблема с тем, что где-то не установлены флаги сортировки или пользователи закрывают окно подбора после выбора каждого значения.

(0) Оптимизировать Подбор-запись

Переписать модули проведения на прямые запросы.
(4) Я отказался от Вашего патча. Долго не мог понять, почему у меня возникали постоянные блокировки, в основном в справочнике номенлатуры. И блокировки именно на чтение. Методом исключения вышел на этот патч. Убрал и все залетало.

Можно обойтись без прямых запросов

(13) А, чуть конкретнее?

Господа, давайте по порядку.
Способны ли SAS винты существенно увеличить производительность, при условии, что других действий производиться не будет?

(14) Из проведения убираешь проверки на наличие товара на складе

(15) Способны.

И контроллер с кешем попольше.

(0) Терминал, диски пошустрее, проц помощнее, памяти побольше. RAID пользовать только аппаратный а не программный. Подкрутить 1cpp.dll для прямых запросов. Ну и самое важное - строить правильно структуру, а то если кривая структура все эти примочки коту под хвост. Ну и оптимизировать сами документы. В общем работы дохрена - было б желание и время всем этим заниматься.

+(19) Иди деньги, чтобы за это заплатить.

(20) Ну а куда щас без денег?.. Думаю и автор за спасибо не станет этим заморачиваться, в случае если прирут - поменяет только диски и скажет что больше ничего сделать нельзя.

(0) Более лучщий сервак + оптимизация базы...

(21) Согласен...

имхо перевод на скуль и прямые запросы будь то той скуль или 1с++ - это твой выход

перевод хотя бы на чтение уже будет приличный эффект, а если еще и на прямую запись переведете так ваще шоколад

"База сильно переделанная ТИС 9.2 . Последне вермя база стала ощутимо тормозить. "
Период сколько времени открывается?

(16) и что это даст?

(24) Перевод на SQL это по меньшей мере 10000 вечно зеленых. За эту сумму можно и сервак очень неплохой взять.

Для начала все-таки попробуй прямые запросы (в части замены "временного расчета" при проведении) - даже в дбф-базе это дает эффект

(12) Не знаю, у нас все работает.

(28) ну тогда прямые запросы к дбф

(28) "Вам шашечки или ехать?" (с) Хто-то...

+32 просто незнаю как 60 юзверей будут нормально работать на дбф. Ну невидел я такого стада на дбф...

+33 Если нехотите тратить денег - дайте зверям счеты в руки и впередд... Глядишь и на компах сэкономите.

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

(32) Вопрос в другом. Что выбрать SQL или новый сервер.

+36 Просто серваку уже 5 лет. За это время он не модернизировался (только памяти добавили).

(36) Скуль и пару серваков (под скуль и под терминал). И еще бесперебойники на них незабудь - тоже денег нада...

если проблемы с блокировками, тогда надо сделать параллельное проведение. тоже с помощью ToySQL :) все в комплексе если делать - получится лучше чем на DBF.

(0) есть ли ускорение если положить базу на рамдиск ?

(26) Период открылся у меня на ноуте меньше чем за минуту.

(40) Стремно, 300-500 документов в день, только реализации.

перейти на скуль и убить блокировки как класс

(42) ты меня не понял, положить на рам лишь только чтобы узнать насколько это даст результата, а если результат будет стоящий, то уже выбрать решение близкое к рамдиску по скорости но надежнее - рам-ферма, SSD и т.п.

для 7.7 2Gb это большая база для файлового варианта.
при этом в файловом варианте оптимизация возможна в основном заменой железа, а оптимизация использования БД не всегда возможна.

при использовании базы такого размера можно попробовать использовать SQL Express, т.е. придется разориться только на платформу под sql.

(45) Не согласен. У меня у клиентов и по 4гб есть и нормально работает. Там только пользователей 15-20.

(45) как работали году в 1998 к примеру ?

(45) Размер базы и размер файла в ДБФ понятия немного разные. Просто когда зверья набегает в базу человек 50 то работать в ДБФ уже просто нереально и других вариантов кроме перехода в скуль нету.

Господа, а какие ограничения у SQL express? На сколько реально его использовать для работы?

(51) ХЗ. Я "обрезками" не пользуюсь.

(51) 1 процессор, 1 гиг озу, 4 гига база
первые два "обходятся" не нарушая и не меняя ничего

(53) третье обходится созданиеб очень большой базы и присоединение ее к уже установленному серверу :)

(0) > Поменять дисковую подсистему на SAS.
смеялсо. кто сказал что диски - это узкое место системы?

(54) не знаю, народ говорит, что с 2005 експресом этот финт не проходи

(55) Я сказал в (19). Если не веришь - попробуй на практике.

Я бы оставил ДБФ, но крутил бы на 4-ядерном проце, диски всё же поменял бы.
W2003 TSR.

(58) А, что 77 более 1 ядра использует?

(59) В терминале - как документ новый создать :-)

(59) Может (58) и прав. Вполне может быть что ДБФ в терминале на х64 на 4-х ядернике и взлетит, вот только низенько низенько. Можна сказать не решение проблемы, а некоторая отсрочка роблемы, ибо када народу будет много наверняка и там сдохнет. Наугад точно никто не скажет сколько проживет эта схема, и проживет ли вообще.

(61)
2 ГБ для ДБФ это не так уж много, у меня ~1.6.
Правда пользователей ~ 20.
Многопроцесорность/ядерность здорово помогает (под терминалом).
На одноядерном были тормоза, перевёл на двухядерный - летает.

выгрузить базу и загрузить...много мусора чистит

А если попробовать альтернативные DBF От Hogik-а
http://infostart.ru/projects/811/
http://infostart.ru/projects/1359/
Или перевести на линукс со слоником от Etersoft-а
http://www.etersoft.ru/

Да, забыл
Есть еще вариант от Pit-а
стоит всего 1000 Евро, но его пока еще никто не видел ;(