Центральная База - Оперативный учет 7.7 DBF, самописная, на основе ТиС, размер базы около 6 Гб. за полтора года. релиз платформы 27, 90 пользователей, активно работающих. Среднее количество проводимых док-в: 3-12 шт./в минуту. База на сервере Win 2003 Enterprise Ed. SP2, все пользователи работают в Терминале. Максимальный размер одного файла БД: 490 Мб. Установлен плагин от Romix Terminal_Sleep, работает без проблем уже в течении 1,5 года.
Одна периферийная база, на другом сервере, размер - меньше, пользователей меньше, проблем не наблюдается.

На днях в центр. базе начались проблемы: периодически, 1 раз в день база начинает у всех пользователей "тормозить", затем "зависать" и аварийно закрываться. Вначале выдаются ошибки блокировки практически всех файлов базы: при этом вместо "мягкой" обработки ожидания захвата таблиц БД, происходит именно зависание этого процесса на несколько минут, затем база выдает ошибки типа "Runtime Error", предупреждения
о разрушении файлов базы 1С (разных), аварийно закрывается и зайти в нее уже нельзя: пользователь не уходит дальше инициализации глобального модуля, который тоже приводит к блокировке.

Ничего не переустанавливалось, никаких доп. компонентов или плагинов, доп. нагрузок не вводилось. База в таком варианте была вполне  работоспособна в течении 1,5 лет. Профили пользователей 1С - маленькие. (не более нескольких килобайт).
Удаление файла 1cv7.mlg не дает никакого результата.
Приходится всех выгонять и перегружать сервер. Что вместе с переиндексацией занимает час. После этого работа идет в нормальном режиме.

Вопрос в том, обязателен ли перевод базы в формат SQL в данном случае и поможет ли он?

не уссественно на sql перегонять надо

DBF и  размер базы около 6 Гб,ваще актуально + 90 юзверей

Самая большая DBF в базе сколько весит?

вообще не должны в дбф работать, тебе что то не дорассказали

Поставь 2003 64 бита + пропатчить файлик, для запуска 1С 7.7
+ 90 зверей за раз в терминале, не могут работать, все разом не могут, система не удержит :)

(2) на SQL будет работать еще медленнее, у меня комплексная 7,7 без индексов 8 гигов и ничего.

(0) размер оперативки и самого большого DBF файла в студию

+ вполне возможно у тебя деадлоки

(6) 8Г - это мелочь.
(0) на оперучете 6Г - немного. Скорее всего, штука в количестве юзверей. у меня после 75 начинает странно тормозить (но не валится), но у меня сиквельная база....

(8) я и говорю, это не повод переезжать на СКЛ

а при переезде на SQL ТС еще могут ожидать сюрпризы из-за разницы работы запросов под SQL и DBF, и придется самописку-то еще допиливать.

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

выбор или Надежность или Скорость

я лично за первое

(0)озвучь ресурсы сервера.что на нем еще кроме 1с 7 крутиться?Антивирус какой,настроены ли исключения.
Проверить память на ошибки,посмотреть системные логи

(0) cfg почисти у юзверей для начала

>>>Что вместе с переиндексацией занимает час

говорит всего лишь о слабой производительности сервера/особенно дисковой системы

(15) от плохого цфг по цепочке все юзеры валиться не станут...

(16) ну, хоть что то.. Хотя, ромиковскую приблуду в первую очередь бы выкинул

(0) - железо сервера какое ?

(17) Насчет приблуды - не факт. хотя попробовать можно. Правда, будет еще хуже...

(19) будет лучше, проверено.
Всем ожидание в 0 тока выставиьт и привет.

А для ТиС.. проводить всегда в потоке + 5 дней периодичность итогов и усё залетает.

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

(21) жестокий ты. В рабочей базе?
пардон, ТКВ....

ну нет:) в своей. фишка в том что я к обеду так сервер задрачивал, что приходилось пергружать.

По поводу того, что не могут 90 пользователей работать и система не удержит: держит как то :)
Размер самого большого dbf  был приведен в первом сообщении - 490 Мб
Железо: Оперативки 16 Гб, Xeon CPU E5335 @ 2.00GHz, база на винтах SCSI в рэйде.
Антивируса не было вообще, после появления проблемы - проверили Касперским, ничего не нашел.
Память на ошибки проверили, системные логи изучили вдоль и поперек - кроме зависших 1Совских длл - ничего интересного.
На сервере бывает еще MS Office пользуются, 2Гис, ну и печатают естественно много.
Сейчас проблем с быстродействием нет: все итак летает. Проблемы только со стабильностью.
Переиндексация занимает 15 минут, не так много для нашей базы. Но вот без Ромиксовского плагина база бы у нас не шевелилась вообще.

(21) По поводу работы в Конфигураторе - интересная идея! Я как раз работаю в Конфигураторе и как раз на рабочем сервере!

темпы на рамдиск уже предлагали?

я бы для начала убрал патч Terminal_Sleep, и установил время ожидания в 0 всем, посмотрел на дальнейшее поведение базы

и ещё: можно серьёзно сэкономить, реализовав механизм "допроведения", т.е. оперативно проводить только остатки, например, а все тяжёлые процедуры типа списания себестоимости и т.п. проводить ночью (если, конечно, у фирмы не режим 24х7)

(26) вроде нет. а поподробнее можно?
(27) Тогда пользователям придется все время жать "Повторить" а это раздражает :)
(28) у нас вся работа ведется в оперативном режиме и проведение любого документа занимает пару секунд. в документах позиций немного (10-20 позиций). нет, режим не 24х7

Вы не переживаете за надежность? 1С рекомендует, я бы даже сказал настаивает на переходе на скул.

(30) дануна. 1С рекомендует переход на 8-ку, а про скул не надо тут впаривать

на скуль однозначно, проблемные места переписать на прямые запросы

(29) 1. ну сделай рамдиск, и при запуске 1с указывай темп на этом диске (параметры ком.строки).

кстати, ещё Aleksey тут оптимизировал файловую базу через перенос индексов тоже на рамдиск

(25) у меня пользователи зависали, когда я делал трассировку в отладчике

(34) это факт

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

Сталкивался с такой же проблемой. Файловые перифирийки стали рушится под конец года, помог переход на SQL.

Проблема с похожими проявлениями возникла перед новым годом(29 декабря...)  - оказалость было дело в системной плате сервера - один сокет с ксеоном пришёл в "негодность" - процессор вынул - с одним никаких тормозов, вставил тормоз - так и стоит сейчас этот сервер в резерве с одной двухядерной головой... Проблема "слабо" проявлялась и ранее несколько раз, при загрузке ОС в основном, лечилось ресетом - тесты ничего подозрительного не выявляли - но пришло время...

(27) А где время ожидания в 0 менять ?

(39) за "0" надо руки отрывать таким людям

походу выгнали гуру, который отладил работу 90юзеров, а сейчас новичек быстро базу завалит

(40) Ты это уже писал где-то. Но все-таки

+Епрст4 в (20) я думаю знает, что советует

А какова принципиальная разница между патчем ромикса и выставлением время ожидания в 0..?

(42) если сделать то, что предлагает (20), то итоги регистров распухнут раз в 6, в "потоке" - это как "коммунизм во всем мире", а при "0" действительно получим "привет"

(43) при 0 обработки буду аварийно завершаться, т.к. 1С не будет пытаться повторить транзакцию, у юзеров терпение тоже не бесконечно кнопки нажимать

(0) Если проц справляется то переходить пока нету смысла. Как вариант убрать с сервера все кроме 1С (потому как изначально так нужно было сделать). Если принтеры к серваку подключены - админу яй** в тиски зажать за такое. Проверить таблицу периодики на пустую дату или непонятно какую (типа лет 5 вперед, или там 17хх).
(25) Конфигурить ДБФ базу на серваке? Мдя... Порекомендуйте руководству нанять толкового программиста.
(20) Насчет периодичности это ты молодца. Прям улыбнуло.

(46) а что - тянуть базу на локальный комп, конфигурить, а потом сливать назад..? накуа оно такое надо? если струткрут данных не менять - конфигурим на сервере. если меняем - предвариетльно бэкап. Принципиальные проблемы в чем? (если только как выше написано что конфигурение мешает текущей работе мистическим образом).
.
???

(0) Что-то я упустил из виду что ли. А что нет инфы про терминальный сервак и вопросы по нему?

(47)в семёрке - тянуть базу - скопировать два файла в пустую директорию - прям так офигенно долго.
а конфигурять в терминале как-то не удобно - да и сервак не виноват
p.s. я программист на Си и после моих программ иногда даже диск в кашу нарезается - так что писать что-то на рабочей машине - опасно - поэтому привык,что всё надо делать аккуратно

(47) Угу. Потому как 6 Гиг это как семечки. И что назад сливать-то? МД-шник который фигню занимает. Так что автору учиться и учиться. Глядишь и 9.х выйдет.
А принципиальная проблема в том что нефиг грузить боевой сервак всякой фигней. Там вон еще и идиоты с офисом кувыркаются. Может и еще чего. Поэтому вполне вероятно что могут просто забить сервачок (темболее он у них весьма дохленький).

(50) скажи это прижимистому директору, с его точки зрения покупать ещеодин сервер за 300 тыс. чтобы народ там в ворде и экселе работал несколько нецелесообразно, потому что он не специалист и тонкостей не знает. в целом ведьвсе работает.
(0) срочно прекращай конфигурятьна рабочем ервере, переносивсю работу на свою машину

(47) Да? А оно вообще ТАК надо? Семерка умеет брать модули из файлов. Это раз.
Про ускорение работы терли здесь уже не одну ветку, это 2.
Автору можно предложить найти стену по-крепче 3. Неумение гуглить и отсутствие мозга детектед, ИМХО.

(51) Легко. Я вообще непонимаю зачем кормить мелкомягких? Ставьте опенофис, линухи, ...
Хотя о чем я?.. Это ж расточительство. Эта хрень столько энергии жрет - выдать калькуляторы и амбарные книги.
Мля, всеравно не то. В калькуляторы ж батарейки нада. В общем с калькуляторами погорячились. Вместо них выдать счеты.
Ну и т.д. А после первых пару бутылок водки мы б с ним пошли все это внедрять в жизнь. Просто нужно находить общие темы и развивать ... А не сидеть и со всем соглашаться.

(0) У DBF имеются заморочки при росте таблиц свыше 1 гига, о которых писал Hogik.
2 гига на таблицу - это физический предел.
Поэтому переезд на SQL я считаю необходим, тем более столько пользователей. Если база не выгружается, см. Unload_dat_fix у меня в личке.

(53) Шел бы ты своих пингвинов окучивать...

Возможные причины торможения можно посмотреть тут
Книга знаний: Ускорение 1С:Предприятие 7.7
Вот например вариант: Удаление 1cv7.cfg
При разрастании этого файла до нескольких мегабайт наблюдается торможение при работе пользователей в 1С.

(53)можно говорить бесконечно. он тоже соглашается, да, но счет не подписывает. и, кстати, 300 тыров это только железо, мелкомягкие еще 200 потянут. а теперь представь что такое полмиллиона в обороте с наценкой процетов 50-100 и сроком оборачиваемости неделя-две. вот примерно так думает комерс.

(57) самый страшный зверь - это жаба. она уже задушила половину населения.

много зависит от ИТ-отдела в этом плане. Если система рухнет - поднять ее так чтобы вошли в нормальный ритм работы - скольо займет? - ну наверное день... скольо стоит простой конторы 1 рабочий день..?
.
поставить ввод заявок на автоматическую основу - не верю что при темпе заявок 3-12 заявок в минуту нельзя хоть част перевести на автоподсосо (из почты, с сайта да похрен откуда). 3-4 человек - высвободится... уже тысяч сто есть...

(58) это не жаба, а бизнес. ведь один сервер есть, работает. на кой фиг еще поллимона вбивать в кусок железа, когда тебе за месяц эта сумма принесет еще столько же

(60) тоже верно... пока петух в попу не клюнет.. ;-)

(45) дануна. а Попытку давно отменили?

(62) и чего в попытку ставить? оборачивать всю обработку?

(63) всю работу в системе... ПриНачалеРаботыСистемы - попытка.... :-)

(63) ну дык Записать()

(64) напомнил про анек, как иностранец в СССР в канализационный люк упал :)

(62) для пользователя попытка превращается в пытку, а для 1С - все обработки переписывать будешь?
(63, 64) +1
(65) какой наивный чукотский юноша )) ...а также спр.Новый(), док.Новый(), УстановитьНовыйНомер(), док.Удалить() и многое другое... :) как говорится "попытка не пытка" здесь работает с точностью до наоборот

Спасибо за советы не работать в Конфигураторе на раб.сервере. Помогло отчасти. Теперь зависания происходят не каждый день :)
Целиком проблема не решилась, но стало легче.
Видимо придется все таки перейти на SQL, хотя....сильно пугает торможение на SQL о котором все пишут.

(24)Ой не лги мне, смерд, не лги.
Если все 90 пользователей запустят какой либо отчетик (Мего-отчет), то ваш сервер умрет медленной и мучительной смертью :)

(68)SQL не решает проблему скорости, он нужен для одной цели.
Снять ограничение на размер БД, т.е. каждая таблица может превысить 2Гб.

(0) > На днях в центр. базе начались проблемы: периодически, 1 раз в день база начинает у всех пользователей "тормозить", затем "зависать" и аварийно закрываться.
.
засучиваем рукава и начнаем отлавливать - особенно если 2"периодически"..? мало ли что может быть.. - может ссылки сами на себя.. как это аукнется в самописных алгоритмах - хз... может циклит где-тов транзакции вдобавок... короче как-то сидим и ловим что происходит... может обмен с УРБД идет? может еще что..?