The Dim!Да да да, один из недостатков файлового режима, это блокировка всей таблицы. Но это только одна явно описанная проблема. Кроме этого, есть еще две очень больших проблемы:
Это не один из, это самый главный недостаток, так как блокировка взводиться на всю базу до конца операции, и блокировка эта исключительная. Уход от таких блокировок дает заметный прирост в скорости.

The Dim!- минимальный объем работы с .1CD на уровне платформы 4 кб. в том случае, когда место в файле заканчивается платформа запосит у ОС приращение ровно в 4 кб. Это плохо, тот же сиквель позволяет задать приращение в произвольном порядке. Тем самым экономя время на опеации по приращению - это очень доогая операция, и тем, что нет фрагментации файла данных;

- т.к. в файловом режиме нет аналога tempdb или подобного механизма... вернее есть но какой-то своеобразный. В общем при работе файл .1CD очень сильно разрастается, при сжатии удается достигнуть уменьшения размера процентов на 10-15 (за месяц) что тому причина, я не знаю. Но вероятно это как-то связано с кэшированием. А результат этого - фрагментация данных внутри самого .1CD файла, что очень негативно сказывается на производительности. Проверьте сами, это просто мои наблюдения.

Это все не очень хорошо, но на современном железе (а топикстартера сервак не из слабых, 300 серия G6 - на сегодня очень шустрая, если не самая в секторе серверов начального - среднего уровня) это будет давать не значительные задлержки в работе. А при наличии рейда, да еще наверняка со своим кэшем, это практически не заметно. Я бы на это внимания не обращал...


The Dim!По поводу того, почему не будет много толку от перевода на сиквель и почему это на одной машине ставить плохо.
Я сказал, что до того как будет найдено узкое место, говорить о приросте производительности при переходе на другую архитектуру нельзя. Вы уверены, что это всё из-за блокировок? Да, несоменно, это вносит свою лепту, но только ли это?

Вот тут буду спорить! Моя практика говорит, что даже для 4-х активных ползователях замена файлового варианта на клиент-серверный на том же самом железе дает весьма заметный прирост скорости. Именно так в наших 5 магазинах (продукты) удалось поднять скорость работы и кассиров и операторов по приемке товара. Задумываться об отдельных серверах имеет смысл только при очень высокой загрузке (большое количество документов за короткие промежутки времени) либо при большом количестве рабочих мест (ориентировочно 15 и более).

The Dim!Почему отдельные сервера?
Из-за многозадачности. Вы установите два сервиса, им нужно процессорное время - много, очень много процессорного времени. А тут еще и клиенты 1С будут на той же машине крутиться. Тоесть, вы с одной стороны избавитесь от блокировок, но с другой стороны, вы увеличиваете нагрузку на процессор, да еще не забывайте, что на переключение контекста процесса тоже требуется время. Ну тоесть, грубо говоря, эффект будет как-будто у вас на той же машине работают в два раза больше пользователей (сюдя по нагрузки процессора и использванию памяти).
А вот это вранье... Нет сейчас ни одной задачи, а тем более связанной с 1с и SQL, которая грузила бы процессор боле чем на 10-15%. Болшую часть времени он просто тупо стоит и ждет. Да при большом количестве пользователей есть смысл разделить эти сервера, но по другой причине: может начать не хватать памяти на обслуживание всех запросов и не хватать пропускной способности дискойо системы. При расположении серверов на одной машине есть огромный плюс: обмен между приложениями идет не через сетевую подсистему а через общую память - а это в тысячи раз быстрее...

The Dim!Igor Glushaevпропущено...

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

Я не убеждаю ТС оставаться на файл-серверном варианте. Я обратил его внимание на "физику процесса".
Блокируется не база, а таблица (или несколько), это все же разные вещи, неправда ли :)
От того, что блокируется 70-80% таблиц в базе, из них пара ключевых, то действительно, разницы никакой...
The Dim!Опять же, насколько даст прирост переход на клиент-сервер вопрос очень тонкий. Про избавление от блокировок - факт, даст. Но что является причиной блокировок и сколько их реально? Вы можете гарантировать, что это, например, не из-за скорости работы файловой системы? Я - нет. Согласен, утрирую, но все же.
Да, я могу гарантировать, что в результате перехода прирост производительности будет минимум 15-20%. И это не на основании каких теоретических рассуждений. Это из практики. Если же нужно под это теорию подвести - то ради бога. В структуре таблиц 1с есть две, которые используются при любой операции с базой. В момент записи на них также накладывается исключительная блокировка. В результате работа с этими таблицами других пользователей при записи других типов элементов блокируется. И плевать, что эти таблицы нужны только для чтения. Первый клиент их забрал под себя в операции записи, и пока она не закончится он их не отдаст. А другая операция записи ждет их, вот тебе и тормоз. Именно из-за этого в файловом варианте при количестве пользователей более 3 и одновременной записи документов эти взаимоблокировки нарастают лавинообразно, не давая работать. Смена типа блокировки с исключительной на разделяемую (а это и происходит при переходе с файлового на сиквельный вариант) позволяет обращаться при операциях записи к тем таблицам, на которые установлена блокировка, но нет реальных операций записи. В этом случае блокировка ставиться именно на ту таблицу, в которую в данный момент идет запись.
Ну и кроме того, я уже обращал внимание именно на железо - далеко не самое старое, и не самое медленное...

The Dim!Igor Glushaevпропущено...

Это все не очень хорошо, но на современном железе (а топикстартера сервак не из слабых, 300 серия G6 - на сегодня очень шустрая, если не самая в секторе серверов начального - среднего уровня) это будет давать не значительные задлержки в работе. А при наличии рейда, да еще наверняка со своим кэшем, это практически не заметно. Я бы на это внимания не обращал...

Обращал бы или нет... вот для того я советую сначала поискать узкие места. Это может быть не заметно при работе с файлом в однопользовательской среде, а в многопользовательской... я с вами не соглашусь. Да еще вспоминаем о блокировках, вы не думаете, что часть времени транзакции уходит на операцию приращения файла? А ведь у 1с есть еще и лог-файл... %)
Вот далось это приращение... Еще раз - смотрим что за железо: HP ML330G6, с НР-ным железным контроллером рейда Р410. Думаю этого достаточно, чтоб понять, что на таком железе принормальной работе файловые операции не могут занимать сколько нибудь значительной время. А так как кроме всего прочего диски собраны в рейд, и контроллер умеет работать со всеми дисками одновременно, время файловых операций (которое для железки и так не большое) сокращается еще больше. В плоть до уровня статпогрешности в измерениях.

The Dim!Igor Glushaevпропущено...

Вот тут буду спорить! Моя практика говорит, что даже для 4-х активных ползователях замена файлового варианта на клиент-серверный на том же самом железе дает весьма заметный прирост скорости. Именно так в наших 5 магазинах (продукты) удалось поднять скорость работы и кассиров и операторов по приемке товара. Задумываться об отдельных серверах имеет смысл только при очень высокой загрузке (большое количество документов за короткие промежутки времени) либо при большом количестве рабочих мест (ориентировочно 15 и более).


4-ре это не 20. Там наверняка ресурсов - и процессорного времени и оперативки - хватает за глаза. У автора, вероятно, не так.
Что является показателем большой нагрузки? Эпирически-гипотетическое число пользователей? Нет конечно, показателем является ЗАМЕР нагрузки на разные узлы вичислительной мощьности, за достаточно длинный период - несколько дней, минимум.

У ТС именно так. 20 пользователей даже через терминал не могут так сильно грузить железо. Но даже если и так, то отказ от терминала и файлового варианта - это уже огромное благо, так как узкое место именно загрузка от терминального сервера.
Теперь по поводу 4 а не 20 - я не зря указал количество магазинов и чем торгуем: есть магазин - где всего 4 рабочих места, есть - где 20... и в обоих случаях - и сиквел и сервер предприятия - на одной машине. Другое дело что машины эти чуток разные. Опять же вернем к характеристикам железа у ТС: минимальный процессор в его серии Intel QC Xeon E5504 2.0 GHz. Согласись, не самый слабый, чтоб не понтянуть одновременную работу 20 пользователей в связке на одной машине. Тоже самое и память... Мои 20 пользователей живут на железе намного хуже...

The Dim!(большое количество документов за короткие промежутки времени) - счет это документ? А счет с резервированием? А реализация? А реализация на 100 позицый + движения по резервам + договор по документам расчета...
Так говорить не корректно.... ИМХО, разумеется
Документ - это документ. Разница только в объемах движений, которые пишутся в базу. И только... Да согласен, что записать 1000 документов счета на оплату, не делающих движений ни по одному регистру не тоже самое что 100 документов делающих движения по 10 регистрам. И мной подразумевались именно второй тип документов... Думаю более 100 таких документов в час, в каждом из которых от 15 до 50 строк, - достаточная нагрузка на сервер.

The Dim!Igor Glushaevпропущено...

А вот это вранье... Нет сейчас ни одной задачи, а тем более связанной с 1с и SQL, которая грузила бы процессор боле чем на 10-15%.Болшую часть времени он просто тупо стоит и ждет.
Речь о 4-х пользователях и сиквиле?

Igor GlushaevДа при большом количестве пользователей есть смысл разделить эти сервера, но по другой причине: может начать не хватать памяти на обслуживание всех запросов и не хватать пропускной способности дискойо системы.
Опять же, каков показатель - большое количество запросов, это не показатель. А процессорное время резиновое?[/quot]
Вот прежде чем начинать говорить про это нужно для начала сделать. На моих серверах (а их 10 штук) я не разу не видел загрузку процессора в пиках выше 30%. Еще раз повторюсь: на своременном железе только сиквелом и 1с-кой практически не возможно полностью нагрузить процессор. А особенно на таком железе как ТС...

The Dim!Igor GlushaevПри расположении серверов на одной машине есть огромный плюс: обмен между приложениями идет не через сетевую подсистему а через общую память - а это в тысячи раз быстрее...
При такой архитектуре связка сервер приложения - сиквель будет рабоать - по сути через интерфейс замыкания на себя, а не через общюю память. 1С умеет работать только по средствам tcp подключения к сиквелю.[/quot]
1с, как и любое другое клиент-серверное приложение, работает через клиента сиквела. А вот как он даные от сервера получает зависит от настроек сервера и клиента. А там есть такое протокол, как общая память...