Здравствуйте.
Компьютер выделен под файловый сервер. Установлена Win 7 64 Pro (на нем установлена база ТиС, DBF). Имеются 5 рабочих станций, на них установлены Win XP и Win 7. Если в базу заходит один пользователь, даже в разделенном режиме, то всё работает отлично. Стоит другому пользователю зайти, как начинаются тормоза. Причем особенность... Тормоза начинаются если пользователь заходит в ту же базу. Если открывает другую, то проблем не возникает. Описание подобной проблемы было http://kb.mista.ru/article.php?id=136. Особенность в чем... Если пользователь открывает базу на одном компьютере (под разными пользователями), то тормозов не наблюдается. Если база открываются на разных компьютерах, то тормоза есть. Попробовал использовать программный кэш (как указано в статье) прироста скорости не заметил. На SQL переходить нет возможности, всё лицензионное. На терминал денюжки нет. Можно ли исправить ситуацию?

Выросло поколение не знающее об особенностях работы семерки в разделенном режиме..

Воткни памяти до упора и сделай рамдиск, помести базу на него. Для рамдиска отключение кэширования некритично.. Ну и архивируй базу почаще, можно прямо на горячую.

(1) Вроде не пацан )

(2)  опасновато

(1) не. этоне особенности работы 1с. это особенности кеширования виндов

(5) Миша, я в курсе, меня не будешь просвещать? ))

(4) Да ладно... ночью делать нормальный бэкап, а каждый час горячий. Даже если последний горячий по какой-то причине окажется неконсистентным - есть высокая вероятность, что предыдущий нормальный.. и с гарантией нормальный - ночной. Вряд ли на базе с 5 пользователями ведется круглосуточная работа.

(7) бэкап можно делать хоть каждые 10 минут. целостностый. Через УРБД например. иметь всегда дубль базы по системе урбд

sql express тебе в помощь.

(9) с чего это? база 1с 7ка в монопольном режиме. гораздо шустрее базы скл. Тем более у автора если типовая, то перевод на скл выдаст сразу хорошие тормоза там. где их небыло

(10) так речь идет про разделенный режим.

(9) не катит
1. Требуется покупать sql-версию семерки - вряд ли будут покупать недешевую и морально устаревшую платформу для всего 5 пользователей.
2. Официально v7 поддерживает лишь sql2000, а для него в бесплатной версии (msde) чересчур несерьезные ограничения на размер базы в 2 гигабайта. Установка же 2008 Express с 10-гиговым ограничением потребует патчить платформу, что в принципе нарушает лицензию 1с.

Если скуль не устроит тогда только терминал.

(13) "На терминал денюжки нет."
Получаем, что рамдиск - единственное решение

(14)Под линуксом есть бесплатные терминалы, только геморно настраивать 1С.

Спасибо, буду мучить RAM-disk.

рам не поможет.

(17) Ну попробовать то можно..

Так есть еще альтернативные терминалы, которые на обычную винду ставятся, например ViTerminal, у него еще триальный период есть в 30 дней - можно попробовать. Вполне норм. решение на 5 пользователей.

(19) Угу, только MS считает, что даже для терминальных решений сторонних производителей нужно покупать TS CAL.

работайте по очереди.

(20) CAL нужны для мелкософтного терминала.
Для других не нужно.

(22) Неправда.
(0) Терминал онли.

(23) сфигали?

(23) Чо за бред ? Пруф

Всех в терминал!

(24) (25) Лицензионное соглашение мелкософта. Консультировался у ихних юристов. У нас тоже между прочим винь 2003 и терминалки стоят на стороннем софте.

(27) Ну в уши надуть юристы умеют, так же ты мог их неточно понять. Где в лицухе ихней сказано об этом ?

(28) http://social.technet.microsoft.com/Forums/ru-RU/c43422cc-8f0e-4e9e-ba2a-6a5cba7a5249/-viterminal?forum=licenseru

(29) Жесть

(0)
Можно установить компоненту 1С++ и потихоньку переписывать тормозящие места.
Выигрыш ориентировочно на 2 порядка

Ктраткий фак http://www.1cpp.ru/forum/YaBB.pl?num=1148038411/24#24
и см ветки форума прикрепленные

Документация 1С++
http://www.1cpp.ru/index.php/Documentation

(31) на 5 юзеров? А ЗП приходящего эникейщика и штатного прямозапросника сравнивали? Да проще тупо железяки проапгрейдить.

(33)
Да хоть миллион вложите  такого эффекта никогда не получите.
Если вообще какой то эффект получите.
Штатно программисту или автору основные отчеты (т.е. то что безопасно) можно переписать за месяц.
Если и на это денег нет - ...

Если типовая - можно пошукать - может у кого есть готовые

(34) Я немного в курсе. Но для каждого клиента свои решения от потребностей и возможностей. Тем более ради 5 юзеров монстра городить. Даже если он на типовой - так это его счастье, а вы его на иглу садите.

сделайте базы распределенными и пусть каждый работает в своей периферийке )

(36)
Я не предлагаю чего то то нового. Этот путь многие проделали еще 10 лет назад и вполне успешно.

Как альтернатива по железу - купить SSD диски в зеркало  и гигабитный канал.
Но это будет предел апгрейда по железу. Дальнейшие вложения бессмыслены т.к. остальные ресурса сервера в файловом варианте практически не задействованы

А тут vandalsvq написал обертку
>>- выполнение запроса на языке подобном 1Cv8
http://infostart.ru/public/20823/
может так проще автору

Вопрос к (0) или кто знает? Можно-ли положить базу в сеть, но "НЕ на Windows" какой-нибудь "сетевой девайс", который корректно сможет раздавать базу 1с?  В теории это должно решить проблему совместного доступа к файлам в Windows?

(40) Новелл ставь...
Или линух с самбой, но тут нужен очень грамотный гур.

(15) (41) никакой гуру не нужен - за смешные деньги покупается лицензия Etersoft-Wine, там же в местных форумах все расписано как по нотам что и как настраивать. И да, настраивается сервер терминалов на linux.

(31) И что, 1С++ включит кеширование диска при пяти подключениях?

(42) Дада, не нужен....
Сам пробовал?

(0) Исправить можно, Железный raid с кешем и батарейкой.

Второй, более дешевый вариант - базу на SSD.

(45) (46) Не болтай ерундой.
Это не спасёт.

(47) Что не спасет? Проблема только в отсутствии кеширования (виндой) при сетевых подключениях. И быстрый диск с быстрым доступом (SSD), и аппаратный кеш на рейде с отложенной записью - еще как спасет. И всегда спасал.

(44) Новел в шару настроить особой подготовки не нужно.

Из ссылки в (0) есть вариант
http://infostart.ru/public/14664/
но проект этот закрыт. Но решение вполне рабочее, тестировалось (и до сих пор работает) в нескольких местах, оттуда мне даже не звонят, видимо работает.

http://www.wirth.ru/load/v7dbnet/1-1-0-2

Клиент-серверное решение для 1С:Предприятия 7.7 DBF

Можно еще вот с одним из этого побаловаться:
http://infostart.ru/public/15211/
http://infostart.ru/public/14664/

(43)
Вроде же крутой прогер, с 1С++ что ли не работал ?

(53) 1С++ решает проблему второго юзера? Хорош тут из письки по воробьям стрелять :)

(53) Каким образом 1C++ выключит виндовое кеширование?
У тебя какой объем обращения к диску был штатно, такой-же и останется c 1C++. Узкое место совсем не там.

Каким образом включит :)

(31) ты не прав. :) 1с++ это конечно оптимальное решение.
Но если денег мало,.. То терминал и хорошие быстрые винты будут дешевле и быстрей. Вон видимо можно еще с (52) побаловаться если сам Орефков советует.

(55)
При чем тут кэш ?

Обсуждать что делает 1С++  не готов, как наверно и другие, ибо все еще 10 лет назад перетерли в 1000+ тем на
http://www.1cpp.ru/forum/YaBB.pl

(58) рецепт из серии
- Машина не едет - тормозной цидлиндр заклинило
- Ставь турбину - поедет.

(58) При том, что время доступа к HDD на три порядка хуже чем к памяти (виндовому кешу). И когда кеш отключается (озвученный в (0) глюк винды при нескольких сетевых подключениях), то любая операция с базой становится медленней в разы. И если известно узкое место, то его и нужно исправлять, тем более исправляется элементарно - либо аппаратным кешем, например на гигабайт, который естественно не отключается при сетевых подключениях, либо просто помещением базы на SSD, у которой время доступа на пару порядков меньше чем у HDD.

(60)
См (38) SSD уже посоветовали.
К сожалению проблема не только в кэше.
Повторюсь - все это уже 100 раз обсуждали
У того же хогика обсуждений на 10 страниц см (52)

(61) Нет логики. Простая установка SSD дает точь-в-точь такой-же эффект как и установка другой оси с нормальным кешированием при сетевом подключении, и все остальные методы.

поднятие темы о падении скорости в ДБФ базе 7.7 предлагаю считать троллингом, тема обсуждалась 100500 раз последние 15лет

Привет! В общем Решение на самом деле оказалось очень простым! сам имею супермаркет хозтоваров... в общем на виндовс7 поднял терминальный сервер, убрал ограничение на количество подключений... Главное все компы имеют Хрюшку или 7
Если заинтересовало то посмотри здесь http://darmoroz.narod.ru/rdt/WinXP-TS.html
я думаю у тебя все будет путем... Мне помогло, я и мои "домочадцы" БАЛДЕЮТ!

(64) К тебе уже вылетели.

Эт ты мне?

(66) нет, товарищу Нуралиеву и господину Гейтсу, чтобы они обратили внимание...

Дак а что тут противозаконного ? %)
у меня все лицуха... :)

Тебе смешно ДенисЧ, а я Е***лся очень долго, и ничего не помогало... а это обалденно спасло всех...
В ОБЩЕМ Я доволен...

(68)ага , лицуха.

(68) "на виндовс7 поднял терминальный сервер, убрал ограничение на количество подключений"
Вот она. Причина. Кстати, на особо крупный уже тянет....

Ладно... видимо у тебя поприкалываться больше не очем...

(72) он не прикалывается, а у тебя прямое нарушения лицензионного соглашения

Элементарно каллы есть? (терминальные лицензии)

(73) Ежли винду не покупали, то и лицензионного соглашения нет и значит оно не нарушено

(75) вот поэтому и выехали за использования пиратского софта

(75) Судят не за нарушение лицензионного соглашения, а за нарушение законов. Лицензионное соглашение только дает пользователю права, и расширяет права пользователя. Иначе быть не может.

(77) да я шутил так. Кстати, ТС первым пунктом указал. что интересуют только законные средства.

Сколько раз ни пробовал БАЗУ класть на рамдрайв - эффекта никакого.

на рамдрайв надо класть папки пользователей. Вот это эффект дает.

(79) на массовых операциях в монопольном режиме - летает. правда, базенки только супермелкие вмещатся.

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

(82) а у меня баз таких давно нет...

А что, бывают большие dbf базы?

(84) у меня рабочая 4.6 гигов чисто dbf + 1 гиг индексы

(82) Нюанс в том, что каталог временных файлов 1с тоже должен быть перенаправлен на рамдиск. Ибо у 1с есть нехорошая привычка его использовать для выборки данных..

(84) ну, у меня максимальная была порядка 23Г (комплексная). Достаточно приличная по объему. Уперлась во что-то в бухподсистеме (типа итогов по субконто, не помню уже)

(86) Ты еще забыл добавить...

Иметь при этом ОТЛИЧНЫЙ Упс, прекрасный сервер и крутые яйца :)

При сетевом доступе к файловой базе никакого смысла рисковать базой в памяти (рамдиск) нет, ибо быстродействие упирается в быстродействие сети, при правильной организации работы дисков (рейд либо ssd)

Можно ТОЛЬКО папки пользователей на рамдиск положить, при этом целостность базы не нарушится если что. Уже эффект будет.

(90) Не будет. У тебя допустим 1 мс. доступ к сети, прибавь время доступа к SSD (0.1 мс), либо к памяти (0.001 - 0.01 мс) - никакой практической разницы нет.

(87) нет, скорее всего у тебя уперлось в отборы по счетам 1SBsel (типа такого) скорее всего в лимит 16 млн записей.
.
я у себя уперся в бухбазе в это очень быстро. Отключил это, бо практически не используется.

(92) в каком месте в конфигураторе отключать отбор по счетам ?

(79) вместо базы на рамдрайв помогает патч dbeng32.dll

"самый простой способ включить кэширование записи для всех файлов- отключить вызов FlushFileBuffers(hFile). для этого для платформы 7.70.025 надо пропатчить файлик dbeng32.dll: ищем последовательность "50 FF 15 40 C0 11 1F", заменяем на "B8 FF FF FF FF 90 90". Теперь 1С не будет делать принудительный сброс файловых буферов на диск при каждой записи, т.е. запись на диск будет кэшироваться и сброс файловых буферов будет делаться средствами самой ОС (для NTFS каждые несколько секунд). Значительно уменьшается фрагментация файлов на диске и отпадает необходимость помещать временные файлы на RAM-диск. Этот метод дает очень хорошие результаты для локального и терминального режимов. Использовать это для сетевого режима не рекомендую, т.к. не тестил и вероятно может привести к повреждению базы."

(93) Не будет. Ибо кеширование дисков в винде при сетевом доступе отключается при любом сценарии. Хоть сбрасывай буфер, хоть не сбрасывай. Поэтому и написано что работает только при терминальном и локальном использовании.

И отключается и на чтение, и на запись.

(94) я не утверждал, что автору (0) поможет патч dbeng32.dll
этот хак для Злопчинский
вместо использования базы на рамдиске
а для автора мой ответ (51)

(96) Там забыли в совете поставить галку отложенной записи в свойствах диска. Иначе винда флушит сама автоматом (сквозная запись)

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

(98) да, 100% гарантий непадения сервака никто не даст и в этом случае вариант (93) не обеспечивает 100% надежности целостности базы
но, скажем, если аптайм сервака исчисляется месяцами/годами и стоимость восстановления дня базы меньше потерь от более низкой производительности, то имеет смысл переводить на (93)
также это имхо хороший вариант и относительно легкий вариант ускорения при монопольных перепроведениях например

Повторюсь- не знаю как там кэш или еще что - использование 1С++ с скллайт или драйвером foxpro сократило время выполнения отчетов с нескольких минут до пары секунд
Проверено на практике неоднократно и изобретать велосипед думаю не стоит

(100) см. (59) Лучше не сказать.
Еще раз - у тебя резко замедляются дисковые операции из-за того что винда отключает кэширование на диске. Никакие 1C++ кеширование не вернут. Винда на файловом сервере отключила кеширование, хоть 1С++++ поставь, оно не включится.
И есть достаточно много способов решить возникшую проблему, а не городить огород.

(101)
А какое решение предлагаешь ?

(102) Куча решений была предложена в этой ветке - поставить ось которая не отключает кеширование при сетевых подключениях, поставить аппаратный кеш (возможно в рейде), купить SSD на 60 гигов. Она копейки стоит, а время доступа к ней намного быстрее чем время доступа по сети, поэтому она так-же решает проблему с кешированием.

(103)
А с чего решили что дело в кэшировании ?

Типичный запрос - возврат 10 000 строк FoxPro считывает в момент меньше сек и без всякого кэширования.

Что SSD к такому же результату приведет абсолютно не уверен.
Алгоритмы то останутся 1С ские - тащить таблицу на клиента - там ее построчно обрабатывать и т.п.

а 1с++ проблему ну никак не решает. У тебя 1С запускается локально, на машине пользователя. База находится на сервере - на другой железяке, к которой время доступа упало с сетевой (<1мс.) до скорости HDD (10мс.)

(104) Потому что в (0) описан глюк известный уже 15 лет. Глюк обсосанный за это время со всех сторон, и который Майкрософт исправлять не собирается.

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

(104) Еще раз - у тебя с локальной машины пользователя идет обращение к железяке, к которой время случайного доступа 10мс. У тебя не локально запрос выполняется. И ограничение не загрузка процессора, а скорость доступа к железяке.

(105)
Ну вообще то я не общетеоретическую проблему обсуждаю.
У нас база проработала на 1С++ 7 лет лет бесперебойно и временем выполнение в районе нес сек.

Я даже не понимаю чего тут спорить - кроме меня таких людей не одна сотня, в т.ч. и на этом форуме.

(0) поставь на сервер Novell Netware

(100) 1с++ требует работы программиста. Причем, достаточно квалифицированного (ибо таки не восьмерка с книжками, дока таки страдает - придется думать).
"железное" решение проще. И в какой-то мере, особенно про 5 юзверях дешевле.

(109) По сети? Не может 1С++ улучшить характеристики железяки. У тебя при сетевом доступе к железяке, из-за глюки винды ухудшились её характеристики. В 10 раз. Неужели ты не можешь понять что происходит? Железяка стала медленней в 10 раз. Железяка. Не 1Ска. Ты предлагаешь ускорить 1С. Но к железяке она так-же будет обращаться к такой-же медленной. Которая работает не со скоростью сети, не со скоростью ОЗУ (как происходит при работе в терминале либо при не отключенном кешировании диска), а со скоростью HDD, у которого очень большое время доступа.

Нормально ремонтировать то что сломалось. Сломалась железяка (файловый сервер)  - её и чинят. А не ускоряют машину с которой идет доступ к испорченной железяке.

(112)
Да в многопользовательском режиме по сети . Под большой нагрузкой

(114) и 1с++ позволяет получать данные с файл-сервера не обращаясь не к нему? или так-де обращается к файл-серверу у которого из-за виндового глюка быстродействие на порядок упало?

При чем здесь 1С++ ?
Данные получает и обрабатывает драйвер FoxPro. Или СклЛайт Орефкова.Или можно свой написать
1С++  помогает преобразовать запрос а также интерпритирует данные вв виде объектов 1С

(116) Ты как студент, который перед экзаменом по биологии только про блох выучил.
Первый вопрос - про блох. Ну тут оттарабанил по полной.
Второй вопрос - собаки. Ну это такие животные. С шерстью. А в ней блохи. И все про блох.
Третий вопрос - рыбы. У них шерсти нет. А если бы была - завелись бы блохи. И все про блох.

(117)
Ну не знаю как про блох вот про это знаний хватило
http://www.1cpp.ru/forum/YaBB.pl?num=1148038411/24#24
Использование индексов прикреплено и рекомендовано
Создание временн таблиц по ДБФ
Запрос к неск базам для ДБФ
и мн. другое

Оставайтесь с нами - Ваше мнение очень важно для нас

поставить SSD на сервак и надеяться, что скорость на сетевой машине в дбф базе дорастет до скорости локальной тоже бесполезно, ибо начиная с 2го юзера пропадает кеширование на СЕТЕВОМ клиенте
т.е. сравнение между RAM на клиент сетевом и связкой Сеть+диски на сервере

В общем так:
Windows использует UDP-пакеты для монтирования файла по сети.
При этом, сервер отслеживает количество подключений к файлу, так как система работает с номерами файлов, которые запрашивает.
Если к какому-то файлу подключаются два клиента, то включается немедленная отсылка изменений на сервер, когда каждый сеанс при записи передаёт что-то на сервер.
Если работает только один клиент, то все изменения на сервер передаются точно также, но сохранённые в кеше клиента данные могут использоваться при повторном чтении файла, без запроса к серверу. Если файл изменяется, то сервер сообщает, что кеш устарел - причём - это сообщение обычно присылается не по каждому файлу, а по группе - чтобы не засорять сеть.
В итоге, когда к шаре подключены более одного пользователя, вся информация запрашивается с сервера, а не из кеша клиента.
Хотя, на самом деле, команда flush, которая должна сбрасывать файлы на диск и очищать буферы, в случае работы одного пользователя выполняется некорректно - буфер сбрасывается, а вот кеш не очищается.

(119) скорость возрастет до скорости сети.
а не до скорости локальной работы.

Нет возможности терминал от мелких поставить купи вайтерминал (он копейки стоит)

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

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

Третий способ - переписать 1С, но, мне кажется, что вместо перехода на 1С++ и т.п. можно просто переходить на восьмёрку и использовать Web-режим.

Есть ещё терминальное решение - аппаратные тонкие клиенты - Microsoft в своей лицензионной политике допустила некоторую оплошность - они посчитали, что если тонкие клиенты работают под Windows Xp, то, так как она настольная, то отдельная версия должна быть куплена на каждого клиента, который с ней работает (при этом даже говорилось, что если центральным компьютером никто не работает, то на него лицензию покупать не надо). Такое рассуждение было сделано, руководствуясь объяснениям функционирования тонких клиентов от NComputing. Плюс здесь в том, что можно подключить до 10 пользователей на одну машину с Windows Xp и не иметь проблем с лицензированием.
http://www.ncomputing.com/products/overview
Правда, сейчас, Xp уже не поддерживается, а в Windows 7 и т.п. эти клиенты так и не заработали.

(123) Чем плохо просто купить SSD за 100$?

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

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

(125) Не работает.

При работе по сети, кеширование диска локальное на сервере - не работает. В том-то всё и дело.

А от операционок это насколько зависит? Может применять стандарты - на сервер, допустим, вин 2003 сервер, на клиентах - хр и ниипет. Вообще проблема не проявляется 100%. Бывает сносно работают несколько компов, бывает уже второй висит намертво.

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

(129) Любая винда отключает все виды кеширвоания при совместном доступе к сетевым файлам.

(130) Основную задержку дает HDD, а не сеть, так как винда отключает любое кеширование при совместном обращении к шаре. А доступ к HDD на порядок медленней чем задержка по сети.

(129) Количество свитчей и скорость передачи пакетов по сети. Каждый свитч пакет сначала получает, а потом только начинает передавать - если их несколько, то скорость передачи запроса уменьшается - получаются тормоза.

(1)
Тема: http://forum.infostart.ru/forum1/topic75715/message807823/#message807823
Сообщение: 16.

http://www.mista.ru/articles1c/hare/article.45.html
вот статья больше чем 10-летней давности. Даже тогда было известно что отключаются все виды кеширования, в том числе и виндовый кеш на файл-сервере. И ничего с той поры не поменялось

Вывод прост – при использовании файл-серверного варианта системы 1С:Предприятие использование сервера под Windows нежелательно. Однако если нет другого варианта – надо постараться использовать максимально быструю систему ввода-вывода (только SCSI). Этот вывод на самом деле действителен для любых файл-серверных приложений (например, БЭСТ), а не только для 1С.

(138)
Еще 10 лет назад пробовали - эффект близок к 0.
Неужели думаешь, что все кто использовал 1С++ всего этого не знади и только время зря тратили ?

Проведи тесты

(138)
Отключается кэширование на стороне "клиента". И никакая дисковая система эту проблему не устраняет. Читайте описание в (134) сообщения.

(138)
А никто не пробовал линуксовый самба-сервер?
Там довольно тонко можно с настройками поиграть.

(141)
Дело в самой сути протокола:
"Samba — пакет программ, которые позволяют обращаться к сетевым дискам и принтерам на различных операционных системах по протоколу SMB/CIFS. Имеет клиентскую и серверную части."(c)
Не пробовал. Но мой сынуля (спец по Линуксам) говорит, что протокол работает одинаково. :-)

(139) какие тесты? я тебе до копейки могу рассчитать ускорение.
HDD, кэш отключен. время доступа по сети 1мс, время доступа к HDD 10мс, итого время доступа 11 мс.
SDD, кэш так-же отключен, время доступа по сети 1мс, время доступа к SSD 0.1 мс, итого время доступа 1.1мс. Ускорение операций доступа к файл-серверу и на чтение и на запись - в 10 раз.

(141) А смысл? файл-серверный вариант семерки  - полнейший анархронизм. у кого критично быстродействие -  либо терминал, либо sql, либо их связка.
(140) отключаются все виды кеширования. многократно проверено за эти 15 лет. А в (143) расчет с отключенным кешированием для hdd и ssd.

(144) "отключаются все виды кеширования"(с)
Нет. :-)

(145) Да. Причем на 100% это гарантирую. Отключается виндовое кеширование на файл-сервере. В итоге остается только кеш диска, 64 метра в лучшем случае, от которого толку как от козла молока.

(143) откуда данные про скорость SSD при отключеном кэши?

(147) В инете полно тестов SSD на время случайного доступа.

Вообще можно просто посмотреть скорость SSD и HDD в IOPs-ах случайного доступа, и получить время доступа поделив секунду на эту скорость.

(146)
Повторю еще раз. Последний раз... :-)
Прочтите ссылку из (134) сообщения.

(148) Просто исходя из твоих цифр, получается что скорость ССД больше в 100 раз, т.е. если я тупо положу базу на ссд, то у меня отчет будет формироваться в 100 раз быстрее, но ведь это не подтверждает практика? нна на 20-30% - да, но не на 5 000%

(150) Читал я эту ссылку, и могу еще раз повторить (146)

(151) Нет. Не скорость SSD больше в 100 раз. А время доступа быстрее в 100 раз. Это разные вещи. Скорость SSD и HDD на последовательном чтении отличается всего-лишь раза в три.

(153) ну т.е. я правильно понимаю что время доступа практически никак не влияет, потому что при увеличении времени доступа в 100 раз на практике мы имеем всего лишь 20% увеличение скорости формирования отчетности?

(150) Прочитай еще и (137), к тому моменту почти 5 лет была известна проблема, могу процитировать
"Этот подарок преподнесен нам особенностями работы механизма кэширования Window NT/2000. Если база лежит на NT/Win2000, то при одном пользователе будет включен кэш сервера, и при этом не имеет особого значения, как пользователь подключен к базе – монопольно или в разделенном режиме. При подключении второго и последующих пользователей кэш выключается."
На сервере отключается виндовое кеширование тоже. В том числе и на чтение. Это факт, а не домыслы. И решали эту проблему и 10 лет назад в том числе и рейдом с батарейкой с большим кешем, и эту проблему он решает.

(154) При доступе по сети - ну никак не на 20%.
На 20% Если ты работаетшь локально, так как у тебя работает виндовое кеширование, в памяти. Для базы dbf можно сказать что вся база лежит в кеше, в оперативной памяти. А при работе по сети ситуация иная. У тебя идет чтение по сети маленькими блоками, где основное значение имеет время доступа, а не скорость памяти, и даже не скорость чтения с диска, которое у SSD тоже в несколько раз больше.

А если база не влезает в память, в виндовый кеш (на пример SQL база на сотни гигов), то разница между хорошим быстрым рейдом на SAS дисках и SSD - в несколько раз даже локально.

(143)
Абстрактные цифры не нужны. Тест простой.Разворачиваешь базу на SSD - отчет по продажам какой нибудь большой базы, перепроведение.
Когда я проверял - SSD еще не было так распостранено было 4 SAS диска и разницы не была значительной.

Самое чтение не является сильным затыком тот же XBase считывал достаточно шустро. Даже 1С ВыгрузитьИтоги неплохо.
Когда же ставились фильтры или сложные запросы - шел затык

(158) Я не буду сейчас проводить подобные тесты, ибо за 15 лет их провели огромное количество. И суть проблемы известна уже как раз все эти 15 лет. И простейшее решение - увеличить скорость работы дисковой подсистемы и самое главное увеличить время доступа диска. Раньше это решали рейдами, кешем с батарейкой и т.д., сейчас это можно решить намного проще SSD диском.

4 SAS диска изменят ситуацию очень мало, потому что проблема не в скорости чтения с диска, а во времени доступа к диску. И в SAS дисках оно не намного лучше чем в дешевом HDD на 5400 оборотов.

+ (159) А от количества дисков в рейде - время случайного доступа вообще никак не зависит, независимо от типа рейда.

(155) "На сервере отключается виндовое кеширование тоже. В том числе и на чтение."(с)
Запускаем две сессии в сетевом режиме. Одна сессия бездействует. Вторая читает последовательно таблицу в 500 мегабайт. Время первого запуска и последующих зримо ;-) отличается. Смотрим обращение к диску на сервере. В первом запуске есть обращение, во втором - нетУ. А про отключение кэширования на стороне "клиента" мы с Вами имеем одинаковое мнение. Да?
(156) "У тебя идет чтение по сети маленькими блоками, где основное значение имеет время доступа, а не скорость памяти,"(с)
Основное значение значение имеет латентность сети и количество пакетов необходимых для получения с сервера ОДИНАКОВОГО объема информации.
(157) "А если база не влезает в память, в виндовый кеш (на пример SQL база на сотни гигов),"(с)
Что такое "виндовый кеш" ? Нормальные СУБД используют/организуют свой кэш. Т.е. открывают файлы с запретом кэширования средствами операционной системы.

(161) В данном случае имеется в виду кеш SQL. Разницы никакой. И еще раз повторю - виндовый кеш отключается при сетевом доступе нескольких пользователей.

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

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

http://opennet.ru/openforum/vsluhforumID1/41204.html
Вот еще ветка.

(163)
А можно ещё проще. :-)
Запустите копирование большого файла с сервера по сети на две машины поочередно.
Посмотрите время копирования. И посмотрите обращения к диску на сервере. Они есть ТОЛЬКО при первом копировании.

http://support.microsoft.com/kb/306981
http://msdn.microsoft.com/en-us/library/windows/hardware/ff547373(v=vs.85).aspx
Вот с сайта Майкрософт.
(161) Или Майкрософт тоже врет?

(165) Чего ты меня лечишь? :) Отключается виндовое кеширование.  Все об этом знают. Что ты хочешь доказать, я никак понять не могу.

Ладно ты не веришь мне, ладно ты не веришь справке от 1С, но Майкрософту то поверь!

(165) По-очередно кеширование не отключится! Ибо нет одновременного доступа к файлу.
А в 1С отключится.

Ибо идет одновременный доступ.

(167)
Я Вас не лечу. Поздно уже. :-(
А провожу реальные эксперименты/замеры прямо по ходу нашей беседы.
А Вы их проводите? :-) :-) :-)

(170) Еще раз повторю - за 15 лет был проведен миллион экспериментов. Эта особенность описана в справке 1С, описана в справке Майкрософт, а ты мне что-то тут пытаешься доказать.

1С держит открытыми все файлы базы.
Если ты просто откроешь в двух сеансах 1С.
потом попробуешь скопировать любой большой dbf базы сначала на одну машину локально, потом на другую - получишь совершенно одинаковую скорость копирования. Ибо нет виндового кеширования.

(166)
Вы, хоть, сами читали эти ссылки? Это имеет отношение к нашей беседе? А?
(171)
"ты мне что-то тут пытаешься доказать"(с)
Вы прочли текст (161) сообщения? Проведите простейший эксперимент. Я его провел час назад. Я эти "эксперименты" проводил многократно при изготовлении вот этих (52) поделок. Участвовал в тестировании и обсуждал с автором нюансы вот этой (51) разработки.
А Вы мне ссылками тычете. ;-) Которые сами не читали. Или ничего в этих текстах не поняли... :-(

(173) Ты мне сможешь объяснить, каким образом разработка кеширующая файл на стороне клиента имеет отношения к виндовому кэшу на сервере?
Еще раз повторю фразу, это фраза от 1С "Если база лежит на NT/Win2000, то при одном пользователе будет включен кэш сервера, и при этом не имеет особого значения, как пользователь подключен к базе – монопольно или в разделенном режиме. При подключении второго и последующих пользователей кэш выключается"

(174)
"Ты мне сможешь объяснить, каким образом разработка кеширующая файл на стороне клиента имеет отношения к виндовому кэшу на сервере?"(с)
Не имеет. :-) Т.к. нетУ проблем с кэшом I/O дисковой подсистемы на сервере. Есть проблема с кэшем на стороне "клиента".
P.S. Вы тест из (161) сообщения прогнали?

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

Вот прямо сейчас запустил копирование по самбе с двух планшетов фильм размером 1.4 Гб. (windows 7)
В системе - свободно 1030, как было до копирования, так и стоит. Кешировано 555. Как было - так и стоит.
Никакого виндового кеширования при копировании не происходит.
CasheSet как показывал около 500 метров Кеша, так и показывает. Но стоит сделать локальное копирование - кеш будет забит.
(176) При этом не работает и локальное кеширование на файл-сервере. Отключаются все виды кеша - и на клиенте, и на сервере.

(161) Опыты с кешированием можно проводить разные, но нужно понимать, что 1С не просто читает данные из файлов. Там используется блокировка определённых областей файла, что в случае однопользовательского доступа системой исполняется на клиенте, а в разделённом доступе - на сервере.
И вот этот момент и замечается - работает сеть или нет.

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

(175) Могу объяснить. Это известный глюк Майкрософт, известный уже 15 лет.

(177) Можно также попробовать выполнять копирование их драйвера и убедиться, что запросы драйвера никто кешировать и не собирался.
Можно ещё выполнить проецирование файла в память и тоже увидеть, что кеш не растёт.

(180) При проецировании в память - кеш растет.
При копировании в NUL кэш растет. Если я буду копировать с этого компа на другой - кеш растет. А если я буду забирать, то кеш не растет.

(179) Кстати, использование проецирования файла в память вместе с чтением файла через дескриптор также даёт некоторые замечательные эффекты, но в случае проецирования блокировки не работают.

Запустил загрузку с одного устройства по самбе (другой файл на всякий случай) - Вся свободная память быстренько уходит в ноль.

Свободно 0, Кешировано 1335

Так что не надо меня лечить. Ничего не поменялось, как было 15 лет назад, так и сейчас. При доступе к шаре с двух сетевых устройств. Кеширование на чтение в винде не происходит!

То что локальное кеширование на клиенте так-же не работает, я думаю доказывать не надо. То есть никакие виды кеша, кроме тех которые на железяке (HDD, рейд) при доступе по сети к файловой 1С не работают.

Прервал загрузку, итог - Кэшировано 1707, свободно 0.
Чего при загрузке одновременно с двух планшетов по самбе не происходило. Происходит локальное кэширование на сервере только при доступе с одного устройства.

Сейчас все дома спят, не могу взять третье устройство чтоб заснять. Завтра вечером могу наглядно доказать с видео, что не происходит кеширования на чтение на сервере при доступе с двух устройств. Что я и пытался доказать последние 100 постов.

(188) допустим, SSD решит проблему со скоростью доступа. А что будет у остальных юзеров, когда кто-то запустит в базе например проведение (читай - запись в DBF)

(189) Основная проблема с отчетами. Почитай первые посты темы. Проведение ускорится только в части чтения с базы (получение итогов и т.д.), в части записи особых изменений не будет. Так как запись это не случайное чтение, и она пишется в кеш HDD. То есть на запись самое медленное устройство это сеть.

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

Интересно, через сколько SSD умрет при обычной работы той же ТиС). Я дома то не рискую работать с базами на SSD

(192) У нас на серваке стоят SSD - SSD кеш на рейде (Несколько баз, самая большая 150 гигов) уже полтора года, ничего с ними не случилось. И время жизни у современных SSD сравнимо с временем жизни HDD. То есть риск можно оценить как примерно одинаковый. Причем когда умрет жесткий диск, не факт что ты с него сможешь прочесть. А когда выходит ресурс SSD, она блокируется на запись, а не на чтение. И есть очень удобные мониторы выработки ресурсов SSD, ибо время жизни (количество операций записи) четко лимитировано.

(193) прокомментируй напоследок утверждения оппонентов о кэше на клиентских машинах

(194) Он отключается. Всё правильно они говорят. Только он отключается не только на клиентских машинах, но и на сервере. Причем на клиентских машинах он отключается независимо от оси на сервере, а на сервере отключается только если там стоит винда. Если на файловом сервере нетварь, то кеш диска на сервере работает. Так как это глюк чисто винды (ядра NT).

Именно на этом и основаны старые советы, в том числе и от самой 1С - ставить нетварь на файловый сервер при работе с 1С.

(196) спасибо. Лично я почерпнул для себя полезную информацию

(96) у мну необходимости в рамдрайвах нет, база дбф, файловая 6гиг (дбф+сдх), терминал. Нормальный сервак. Пашет будь здоров - тянет в торгбазе одновременно 25 юзверей, даже не спотыкается 9с учетом того, что человек 10-15 ходит со складскими терминалами).
.
но вот ждет ли меня такая лепота на снеговике...?

..да и прямых запросов в алгоритмах проведений нет.

вот еще такая шняга есть
http://www.wirth.ru/publ/test_1_v7dbnet/1-1-0-1
тоже может помочь
.
рщпшл вроде тестил немного - говорил, что работает вроде ок

(177)
Ну, т.е. это Вы так проделали тест из (161) сообщения? :-)
И так все 15 лет делали? У меня нет слов... :-(

Понимаю. Вам бесполезно что либо показывать/доказывать.
Но, может других читателей темы это оградит от Ваших советов.

Замеры трех запусков чтения справочника:
236.105 сек.
167.502 сек.
165.619 сек.
Во втором и третьем тесте обращения к HDD на сервере нетУ.

(201) Вы запускаете чтение с одной машины.
Я же наглядно завтра вечером докажу что при одновременном чтении файла с двух клиентов - виндовое кеширование отключается. Не уменьшается свободная память на сервере, нет кеширования. Отключаемся, подключаемся только с одного клиента, читаем файл - свободная память на сервере уменьшается, кэшированная растет.

Что вам не нравится в этом тесте? Это тест как раз показывает работу с файловой 1С по сети с нескольких клиентов.

Могу вам еще десять раз скинуть цитату от 1С с советом использовать нетварь, так как на NT отключается виндовое кэширование на сервере (на клиенте кэширования при доступе с нескольких клиентов не будет под любую ось)

Ваш тест это частный случай, когда один сеанс полностью бездействует. Но так не бывает.

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

(201) Я все 15 лет переводил людей на терминал, еще раз повторю - цитата с отключением кэширования это от 1С.

Любой тест с нетварью показывает что скорость формирования отчетов по сравнению с виндой вырастает в разы - это как раз следствие глюка винды с отключением кэширования на сервере. Так как кэширования на клиенте при работе файловой 1С нет ни под одну серверную ось.

(201) А тест в (161) вообще ужасен, ибо при таком сценарии возможно не отключится кеширование даже на клиенте.

(202) "Вы запускаете чтение с одной машины."(с)
Вы меня извините. Но, про собственное лечение - Вы не ошибаетесь. :-)
Вы, чего у меня за спиной стояли? Или Вы это придумали? Вам это показалось... :-)

(202) "Могу вам еще десять раз скинуть цитату от 1С с советом использовать нетварь"(с)
Не надо. :-) Когда 1С писала этот совет, мне уже довелось работать с NetWare и клиентом для Windows. Дык, в нем и делают кэширование на стороне клиента при совместной работе с файлами. Работало не очень надежно. Но, быстро... :-)

(202) "Так как вы постоянно ссылаетесь на свой, абсолютно ненужный тест, я так понимаю что согласны."(с)
Очень странный вывод.
(203) "при таком сценарии возможно не отключится кеширование даже на клиенте"(с)
Точно! :-) Как я не догадался. А разное время выполнения теста в трех запусках мне привиделось. И я конечно забыл посмотреть объем переданной информации по сети.

P.S.
Зря Вы кипятитесь. Это мешает Вам думать. :-)

(207) hogik , вы умеете вести диалог? Вы так и не ответили на мой вопрос, насколько я понял что вы уже поняли что не правы, и начинаете вилять.

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

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

(207) "Вы так и не ответили на мой вопрос, насколько я понял что вы уже поняли что не правы, и начинаете вилять."(с)
Где Ваш вопрос?
Это:
"Так как вы постоянно ссылаетесь на свой, абсолютно ненужный тест, я так понимаю что согласны."(с)
Я на него уже ответил вежливо. Могу ответить грубее. :-)
И где Вы нашли моё виляние? Я продолжаю утверждать, что Вы заблуждаетесь. Попутно пытаюсь дать Вам информацию для размышления по ТЕХНИЧЕСКОМУ аспекту нашей беседы. Она до Вас не доходит. :-)

(209) На вопрос вы не будете отвечать? Еще раз его повторю.
hogik , Вы согласны что при сетевом обращении на чтение к файлу в винде с двух клиентов, кэширование виндой на сервере этого файла отключится? Да или нет? Хотя я уже понял что вы на него отвечать не будете, ибо знаете что неправы, и простейший ролик докажет вашу неправоту.

(210)
Я уже Вам сказал. Вы заблуждаетесь. Сказал это с первого сообщения данной темы.
И престаньте давит мне на глаз. :-)

(210)
Нет. Я Вас обманул - не с первого сообщения. С четвертого. Т.к. первые три Вы не осилили... :-)

(211) Заблуждаетесь - это да или нет? Насколько я понял вы так говорите нет, не согласны. Так вот, я выложу ролик, в котором в только что загруженной винде аналогичной (0) - Windows 7 pro x64 (для чистоты эксперимента), запущу диспетчер задач, подключусь двумя сетевыми клиентами, и буду читать один и тот-же файл. При этом значение "свободно" не уменьшится, а значение "кэшировано" не увеличится. После этого отключусь с обоих клиентов, подключусь одним, и поставлю тот-же файл на закачку, и естественно при этом значение "свободно" начнется уменьшаться согласно скаченному объему, а значение "кэшировано" соответственно увеличиваться. И так-же несмотря на повторное скачивание, файл будет читаться с диска. И посмотрим что вы на это скажете.

(213)
Блин. Ну, Вы чего? Посмотрите (145) сообщение. Там дан конкретный ответ.

(214) Ничего конкретного там нет.
Речь идет о двух видах кэширования - на клиенте, с которым вы согласны что он отключится, и виндовый на сервере, с которым вы не согласны. Все конечно не отключатся, ибо я неоднократно говорил что кэш жесткого диска естественно работать будет. Но уже почти 150 последних постов речь идет только о виндовом кэше на сервере.

Так вот - тест в (213) наглядно докажет что при доступе к файлу на чтение с двух клиентов виндовый кэш на сервере не работает.

(214) Ну так и скажи просто поговорить хочется :)
Это тему отключения кэширования уже обсасывали и пытались обойти (безрезультатно) уже больше 15 лет, нечего тут уже спорить по большому счету, все известно, все пути обхода известны, но коли у ТС нету денег на терминал (на 5 юзверей там получится то 10 тыщ наших рублей), то и денег на SSD у него тоже не будет, так как он тоже не меньше этих 10 тыщ стоит.

(217) ДБФ базы маленькие, а SSD на 64 гига со скоростями 500/500 стоят меньше 3 тыров рублей. И дбф база любая на такой SSD влезет с запасом.

(218) Ну чтобы получить 500/500 это как минимум SATA3 должен быть, а не факт что в сервере он есть, так что вероятно еще планка PCI-ная нужна с ним, да еще не факт что встанет, вообщем вопросов много :)

(215) "Ничего конкретного там нет."(с)
Чего у Вас с логикой? ;-)
Как я мог увидеть работает или не работает аппаратный кэш диска.
Моя фраза: "Во втором и третьем тесте обращения к HDD на сервере нетУ."(с).
Вы из этого можете сделать вывод, что я говорю НЕ о системном I/O кэше (в Вашей терминологии - "виндовый на сервере") ?

(219) Можно взять и медленней SATA2.
Для случайного доступа пакетами в 1Кбайт расчет был выше приведен.
Пусть есть HDD на 100 IOPs при таком пакете, и медленный SSD на 10000 IOPs. Суммарные задержки - сеть максимум 1мс (у меня такую задержку дает WiFi при 10 подключенных клиентах на пакете в 1024 байта). HDD 10мс. (кэш HDD при случайном доступе работать не будет, так как он в 100 раз меньше базы) SDD 0.1мс.
Итого задержки на случайном доступе с пакетом в 1024 байта HDD+сеть 11мс. SSD+сеть 1.1мс.

(220) Видео приведите, как после совместно чтения с двух клиентов файла с виндового сервера, при повторном чтении не идет обращения к диску. Я видео (213) вечером выложу.

(220) Жду кино. И покажите, что идут обращения к диску сервера при запуске двух читающих справочник сессий 1С-а. Ага? :-)

(206) "довелось работать с NetWare и клиентом для Windows. Дык, в нем и делают кэширование на стороне клиента при совместной работе с файлами. Работало не очень надежно."

Вообще удивительно, что оно в принципе работало. Первый клиент  хочет прочитать файла, и при этом не знает, что второй его уже изменил и на сервере уже лежат другие данные. Как при этом реализовать блокировку данных и транзакции? НИКАК! Единственным вариантом могут быть некие дополнительные расширения протокола работы с файлами по сети, когда клиент при изменении данных в файле анонсирует через сервер эти изменения всем остальным клиентам, у которых открыт этот же файл. Как минимум на уровне "файл изменен - кэш на чтение сбросить". Но тут получаем лишнюю нагрузку на сеть.. хотя, наверное нужна экспериментальная проверка.

Поэкспериментировал... Получил интересные результаты. ТиС, ведомость по контрагенту за месяц. В "монопольном режиме" 15 секунд, в "сетевом" (два пользователя):
- "без вмешательств" 90 секунд
- "RAMDisk", "SuperCache" 90 секунд
- "MS SQL" 75 секунд
- "DBEng32" 60 секунд

+(225) Попробую на РАМ перенести папки пользователей...

(225)
О чем и говорили.
Еще попробуй примитивный отчет на 1с++ FoxPro или sqlLite

(227) Ну так то тоже верно. NS не совсем прав, что от 1С++ не будет никакого толку. В частности, если знать, как работает запрос к регистру остатков и "Рассчитать регистры на", когда оно перекладывает данные из таблицы регистра в локальный каталог пользователя, а потом еще раз оттуда получает данные. И все это по тормозному каналу "с отключенным кэшем винды". Тогда как при нормальном запросе через 1С++ данные считаются лишь один раз в небольшом объеме.

(223) при чем тут 1с? при любом чтении.
(228) это не говорит о том что не надо решать возникшую проблему.

Хотя я увидел пост, где 1с++ в плюс к SSD имеется в виду - (38). Я его чесслово не видел :)

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

(229) Решать надо, решаться может по разному. Например у нас для старой базы NAS Synology немного поработал в качестве файлового сервера.
(230) ;-)

Да вроде каждый прав по своему.
способ 1 : Есть как бы путь улучшения сетевой файловой системы
способ 2 : это использовать 1с++ - уменьшаем колво (кардинально) передаваемых данных по сети и избавляемся
от лишних сортировок на клиенте.

Как бы можно использовать оба этих способа вместе или только один из них.

(231) а лучше отчет с большой выборкой (без запроса). так же одновременно.

А если поставить виртуальную машину и на неё положить базу?

(206) Основной совет всегда был отключать кэширование на клиентах NetWare (File Cache Level = 1) при открытии файла несколькими пользователями. В противном случае база просто умирала.

А выигрыш в производительности получали как раз за счет кэширования на сервере.

(237) А интересно, идею с синхронизированной иерархией клиентских кэшей в каком-нибудь протоколе доступа к файлам реализована?

(220) я смотрел твой тест. ИМХО, он некорректен для данной ситуации, так как у тебя последовательное подключение пользователей и чтение, а здесь разговор именно об одновременном.

(201) "во втором и третьем чтении обращений к серверу нетУ" - ну и неудивительно, работает локальный кэш на клиентской машине.

(238) Это как?

(241) это он имеет ввиду, наверное, механизм аналогичный которому реализован в DNS, когда повторный запрос на то же имя не уходит дальше кэша

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

(243) Так это и есть Oplocks level 2. Только в винде он отключается, а в нетвари, если включен - вызывает крах базы.

(225) а почему не хочешь dbnet попробовать? я сколько раз ставил - проблем не было, цена вопроса всего 1тр, до 3 пользователей вообще бесплатно

(244) "в нетвари, если включен - вызывает крах базы"
А почему?

В теории есть кеш на клиенте, с флагами об изменении.
Если версия файла неактуальна, то сетевой координатор обращается напрямую к виндовому кэшу, и только если файла там нет, то идет обращение к диску.
На практике, при совместном доступе и кэширование на клиенте, и кэширование серверной виндой отключается.

Я сейчас точно не вспомню при каких условиях кэширование на сервере отключается (при совместном доступе отключается просто гарантированно, но отключается и при других условиях), но прикол еще и в том, что пока клиенты не закроют файлы (а 1С держит файлы открытыми) кэш обратно не включается.

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

(246) Это уже слишком глубоко для меня. В 99-ом и 2000-ом был вал клиентов с умершими базами именно на нетвари с включенным level 2. В подробности никогда не вдавался. Только всегда знал что это нужно отключать.

+(225)
Установил "V7DBNet". Результат по скорости как в монопольном режиме :-) Вопрос только в покупке "лицензии".

(249) Кто-нибудь юзал V7DBNet - решает «проблема второго пользователя» в DBF базе
http://www.wirth.ru/forum/9-11-1
Если не вызывает смерти базы, то конечно это лучший вариант.

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

(247) Теперь включается:
http://technet.microsoft.com/en-us/library/ff625695(v=ws.10).aspx
Теперь они придумали, что клиент может получать блокировки "в аренду", то есть на время, и попытки этого будут делаться перед обращением к каждому файлу.

Также, если ключи реестра, которые позволяют вообще отключить блокировку на клиенте (то есть, чтобы один работал как два).

В описании кеширования, сказано, что кеширование вообще работает только на клиенте, просто, если на сервере файл "заблокирован" одним клиентом, то с клиента на сервер данные передаются в отложенном режиме. Кеширование на сервере, возможно, включается только из-за того, что идёт передача всего буфера целиком, а не по отдельности. Другими словами, передача данных будет с клиента на сервер будет идти только тогда, когда заполнятся буферы или будет закончена работа с файлами. Большой объём пакета данных потребует на сервере дополнительной памяти. В случае жен выключения блокировки передаваться будет каждая операция чтения-записи. В этом случае, от сервера не требуется большого буфера под данные, так как размер пакета намного меньше. Однако, кеширование на сервере всё равно будет работать, так как данные файлов, передаваемых по сети, не выровнены по границам секторов, а для записи на диск требуется выравнивание. Но, надо понимать, что "умная" операционная система не умеет объединять много маленьких запросов к диску в один большой, из-за этого, в кеш лягут только некоторые (несколько последних запросов), а в силу их размера мы просто не увидим никакого прироста.
Тот же "фокус" можно проделать и с любым файлом - если выполнить несколько мелких операций чтения-записи, то не все они окажутся в кеше, так как там есть предел не только на размер данных, но и на число операций (иначе будет сильное торможение из-за необходимости просмотра всего кеша при каждом обращении к диску).

Если у кого есть Windows 2012 server и клиенты на Windows 8, то можно попробовать включить SMB3.0 и посмотреть, что там реально изменилось (к сожалению, на более "мелких" версиях 3.0 не работает).

(252)  По тексту похоже что речь про запись, а не чтение.

(250)
Там же даже график показан честно
http://www.wirth.ru/publ/test_1_v7dbnet/1-1-0-1
с скллайт 10 сек супротив 196
Аналогичные будут и с фокспро
Правда непонятно зачем тогда   V7DBNet - и без него все хорошо

(254) Не совсем понимаю что ты имеешь в виду под фокспро. На сервер ставится СУБД подменяющая файловый доступ? Если не ставится, то не будет аналогичного результата.

+ (255) Ибо все проблемы с кэшированием вытекают из винды на сервере, и никакими изменениями клиента кардинально эти проблемы не решить.

(254)
Вы несколько о разном говорите.
Понятно, что если грамотно переделать запрос через фокс или sqlite, то выиграть можно много. Вопрос как оптимизировать работу, не изменяя базу и запросов.

(257) Речь идет естественно об ускорении без переписывания кода. Только установкой компонент. Иначе это слишком дорого в контексте (0).

(257)
У него автоматом переделывается ?

У Вирт ру

(44) если б не пробовал, не советовал бы.
набор софтин примерно такой:
FreeNX - сервер терминалов
Etersoft Wine - для работы 1С
Samba - в целом необязательный компонент. нужна только для типа выгружаемых из 1С документов.

(260) Ничего переписывать не надо насколько я понял.
Ставится на сервер СУБД, подменяющая файловую базу прокладка, и подменяются dll на клиенте. При этом с самой базой работает прокладка локально на сервере (при этом работает кэширование на сервере, так как нет сетевых подключений к файлам базы), и работает локальный кэш на клиенте.

То, чего установка 1С++ на клиенте естественно не сделает.

и да - 10-20 пользователей одновременно на обычной машинке с AMD Phenom x4, soft RAID-10, 6 GB. Вот как-то так оно и было

(258)
Тогда имхо, самое лучшее решение это поставить V7DBNet - уже ускорит и решит проблему второго пользователя. Другое решение - терминал. Но если делать по-честному, то дороговато. Третье решение - эксперементировать с другими серверными осями - NetWare, попробовать самбу линуксовую.
После выполнения одного из этих пунктов дальнейшего ускорения можно добиться, применяя 1С++, 1sqlite, FoxPro путем переписывания "узких" мест на прямые запросы.
Помимо этого, просто загрузка 1С++ уже несколько ускорит работу интерпретатора 1С, за счет включенной в него TurboBL и еще нескольких трюков.
Далее немного шаманства с каталогами юзеров на рамдрайвах.
После этого семерка превращается в убийственно скоростной болид. Однако рулить им смогут только шумахеры.
Для руления поможет накатить опенконф с плюшками, и заполировать TurboMD.

Вот так, я считаю, это современный джентльменский набор уважающего себя клюшечника.

(265) Этого ничего не требуется. Достаточно связки SQL + терминал, и нормально переписать код без внешних компонент.

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

(265) Samba почти никакого выигрыша не даст. пробовал. только сервер терминалов

+ к (265) А может ms sql exspress в качестве серверной оси?
но как бы из 0 не ясно какая 1с купленна.

(266)
С этим сложно спорить, конечно стоковый мерс лучше тюнингованного зубила.
Вопрос только в стоимости. И даже в сложности сейчас заиметь легально скл-семерку.

(265)
Уважаемый orefkov, я вот заинтересовался использованием 1sqlite для 1Сv7, погуглил с целью найти какую-нибудь документацию и не нашел ничего, что помогло бы начать полноценное использование этой компоненты с нуля (есть отдельные статьи, на инфостарте пример отчета, но сложно понять принципы использования без вводной информации). Вы не подскажете, как лучше начать изучение компоненты 1sqlite? Возможно какие-то ссылки с описанием (кроме того, что выдает гугл), файлы с документацией и т.п.?

(271) doc.chm в архиве с вк, более чем достаточно.

(271)
Собственно, использование самой компоненты расписано в документации. Дальше надо просто разбираться в структуре данных семерки - что где лежит. Знать язык sql.
Ну и знать, что хочешь получить.
Да, так будет проще - поставить для начала конкретную задачу - сделать к примеру такой-то отчет, и с помощью мисты и форума 1С++ решать ее.

(273) Спасибо за ответ. Я изначально невнимательно просматривал сайт с компонентой и не заметил, что там есть файл с документацией. Начну с ее изучения.

ветку не читал, но осуждаю!(с) )))

а по теме, да - размещение базы, каталогов пользователей и tmp файлов на RAM диске + терминал = делают клюшки убийственно быстрой! лично экспериментировал с различными вариантами.
но для базы в продакшене это очень рискованный вариант.. RAM диск можно использовать для регламентных работ, например перепроведение или закрытие какого нибудь периода.. или для отчетов.. кактотак

..придешь бывало к клиенту, а восстановление последовательности в ТиСе может занять пару часов, а ты ррраз, и на нетбуке перепровел всю базу за 20 минут!))) это с выгрузкой/загрузкой..

на нетбуке у меня 16 Гб памяти, SSD и целерон 1.5

(221)
"Итого задержки на случайном доступе с пакетом в 1024 байта HDD+сеть 11мс. SSD+сеть 1.1мс."(с)

Подобные рассуждения не имеют никакого отношения к работе с DBF файлами по сети.
При отключенном кэшировании на стороне "клиента" (более одной сессии), для получения каждой записи таблицы по сети передаётся несколько пакетов в обе стороны. Кроме этого блоки индексного файла читаются многократно одни и те же. А еще и с эксклюзивной блокировкой всего файла на время поиска записи по ключу и при последовательном движении по индексу.
А с учетом латентности это делается со скоростью ниже 30 МБ/сек (для сеть 1Gb).
Именно уменьшением количества пакетов и увеличением их размера путем чтения файлов большими блоками достигается высокая скорость при выполнении запросов на FoxPro.

(272) который давно устарел, и там нет всех последних фишек

(277) Мы еще с кэшированием не разобрались.
Сейчас перекушу, и убедимся что вы как минимум четыре раза сказали чушь.

(227)
Не утруждайтесь. Ваш метода "поиска" кэша - полный бред.
Тестируйте, как я Вам сказал...

(280) -> (279)

(280) И что не так в этом методе? Когда повторное чтение опять читает с диска?

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

(282)
А давайте заканчивать нашу беседу?
Мы изложили в теме свои противоположные мнения.
Пускай теперь другие специалисты делают выводы...

(283) У меня только что опять получилось прочитать без кэширования, сейчас еще раз попробую снять.

(283) Похоже ты прав. Используют фичу сетевого (клиентского) кэширования чтоб не отжирало память, вынося данные которые использует программа на быстрое сетевое хранилище. А не фичу отключения локального кэширования.
Мне давали статью с глюком отключения локального кэширования, но я её пока не нашел, и нормально повторить глюк не смог. Из десятка попыток один раз не закэшировалось, и один раз при последовательном чтении с двух клиентов одновременно пошло два потока чтения файла с диска (файл небольшой, места свободного навалом, читали примерно синхронно, одно и то же место).

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

(286) Короче локальный кэш точно сбрасывается, но не при чтении с двух сетевых устройств. Я никак не могу найти статью в которой четко описан баг, хотя я её точно видел, но вспомнить не могу как это происходит. Мне в голову уже лезет бред что при чтении каталога со второй машины. Но не факт что это именно так.

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

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

(288) Из-за отключения кэша. Точно отключается кэш на клиенте, и wildhare писал по этому поводу, и 1С, и мне точно давали ссылку на Майкрософт что ошибка до сих пор не исправлена - возникают какие-то проблемы с кэшированием на сервере. Но мне сегодня нормально воспроизвести ошибку не удалось.

(289) итого: при подключении второго юзверя локально - отключается кэш на клиенте и что-то там с кешем на сервере?

(290) Да. Могут быть еще проблемы с сетью, так как работа идет малыми пакетами. Но тут рекомендации не поменялись с 2000-го года. Оставляем из протоколов только TCP/IP, поднимаем домен, ставим умные роутеры, делаем быструю сеть.

Кстати, у кэша есть еще один глюк  - если копировать большие объемы информации (например бэкапы в сотни гигов) на удаленный сервак, то он тоже ложится. Причем если для похожего глюка при локальном чтении есть куча программ для очистки кэша, которые проблему устраняют, то для этого случая я ничего не нашел. Всякие CacheSet и аналоги тут не помогают.

(290) Там не кеш отключается, а исключается объединение пакетов записи в один, то есть в случае, когда к одному файлу обращаются два клиента, то каждая попытка записи заканчивается передачей блока записи на сервер (и отработкой его там). Соответственно, чтение уже записанных данных приводит к отправке запроса на чтение данных с сервера, то есть те данные, которые были переданы в сеть, будут потом переданы обратно.
Есть ли кеширование на сервере, в данном случае, не столь важно, так как запись в dbf-файл обычно занимает 2-3 сектора диска.

Что касается решение проблемы кеширования, то Microsoft и не собирался её решать - у них был придуман замечательный алгоритм работы с автономными файлами, который позволяет получать актуальные версии автономных файлов на клиенте, сохраняя их на случай Offline-доступа (когда сервер недоступен) - самое главное - в Microsoft предполагали, что нужно отслеживать версии файлов и предотвращать запись в один файл с нескольких рабочих мест - то есть они хотели вообще отказаться от многопользовательского доступа к файлам, так как это снижает количество покупок SQL-сервера.

(292) Речь не про запись, а про чтение (отчеты).
Без кеширования, когда много запросов в очереди, получается случайный доступ к диску. При этом максимальные пакеты по 64К. Это ограничение SMB. То есть упираемся даже не в скорость диска, а в время доступа к диску, что медленней  прохождения пакетов по нормальной сети.

(292) То есть как не собирались? У них новый протокол SMB 2.1, который улучшил кэширование на клиентах.

(261) Поддерживаю. На ubuntu и w@e 5 лет так 7.7 работает. Проблем в производительности нет.

А по теме: 5 рабочих станций это вообще ни о чем.

Весело было недавно:
Купили тут дурики сервер за лям, ага, круто!
А вот батарейку для рейда с гиговой памятью забыли!
Рейд перешел в режим сохранения данных и усе накрылось.
Ну из 1С еще и печатают... Странно да?
И вот так совпало, что еще и дрова для принтера не подобрали, поэтому в спулер полетели гигабайты...
Все! Финиш! 32гига оперативки засраны спулером (ну не успевало все это записываться), 16 процессоров думали как и куда этот хлам девать, рэйд-контроллер наверное готов был застрелится ;)

(294) Я писал, что вышел даже 3.0, но это так - улучшения поднятием максимальных ограничений - теперь пакет не будет не более 64К.

Только вот 1C это мало поможет - при формировании отчёта из dbf-файла читают одну запись - соответственно - с сервера на клиента в одном сетевом пакете будет передаваться одна запись.
Теперь - сколько записей нужно выбрать в отчёт - столько сетевых пакетов и отправится на сервер.
С диска-то они читаться будут секторами и, скорей всего, страницами - то есть два запроса могут попасть в одну страницу, которую сервер сохранит в памяти.

Добавь виртуальной памяти везде до 2100. Опять же делай отдельный сервер для пользователей программ 1С. Следи за свободной памятью ПЗУ.

(285)
Сергей (NS).
Вот, не могу найти объяснение - на ЧТО уходят 63 секунды (замеры 4, 5).
Какое Ваше мнение по этому поводу?

Провожу такой тест:

Последовательное чтение справочника по наименованию из одной сессии.
Второй пользователь (сессия) бездействует. На каждом ПК по одной сессии.
Шесть запусков без перезагрузки сервера и без перезапуска первой сессии.

Один пользователь.
1) 2 сек, нагрузка сети 99%, диск на сервере читается.
2) 1 сек, нагрузка сети 0%, диск на сервере НЕ читается.
3) 1 сек, нагрузка сети 0%, диск на сервере НЕ читается.
Запущен второй пользователь.
4) 233 сек, нагрузка сети 23%, диск на сервере НЕ читается.
5) 170 сек, нагрузка сети 23%, диск на сервере НЕ читается.
6) 170 сек, нагрузка сети 23%, диск на сервере НЕ читается.

тупо как ламер - м.б. перекидка заданий на сервере пр процессорам как-то на это влияет..?

(299)
Не. Тут, думаю, лучше говорить - не на ЧТО они уходят, а откуда они берутся (улучшается) на 5-ом запуске. Т.е., типа, еще один кэш образовался. А где и какой?

(285)(299)
Повторил замеры. Посмотрел внимательнее.
В 4-ом замере загрузка сети, больше похоже, на 17%.
Т.е. время исполнения НЕтупо поменялось. :-)

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

(302)
Не. Полное, реальное время чтения с диска меньше двух секунд. Это мы наблюдаем в замерах 1, 2, 3. А тут разница в десятки секунд. Да, и обращения к диску я смотрю на самом нижнем уровне, что позволяет сделать ОС. Вот... :-(

(303) Тут только если tcpdump-ом словить пакеты 4 и 5 и сравнить diff-ом

Ситуация, когда кеш на сервере выключается - это когда один пользователь по сети, а другой - локально. В этом случае, к файлу имеет доступ драйвер сети и процесс локального клиента - а они между собой кеш поделить не могут и тупо его чистят при каждом обращении.
То есть, два по сети к третьему будут быстрее, чем один по сети, а другой локально - много раз проверено.
P.S. можно локально заходить в базу через шару на машине, тогда кеширование ещё как-то работает.