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

холиварчик продолжается :duel:
восстановлю ниточку, чтобы понятнее было

вот на этом моменте вы сказали практически то же, что и я .
я вам просто предложил проследовать сюда _http://www.microsoft.com/en-us/download/details.aspx?id=17190
это всего лишь документ производителя ОС о том, как планировать нагрузку на сервера rdp, там много интересных и правильных мыслей.
если вы его глянули хотя бы краем глаза, то поняли бы о чем я, а заодно поняли, что я по этому документу проходил уже не один раз

про сервер. только не 1с, а rdp

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

да, про него.

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

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

и где тут "нужно несколько голов, но не нужна многоядерность"? несколько голов как раз относятся к планированию сервера терминала, а многоядерность - к клиенту 1с, который ни разу не многопоточный, соответственно в одиночку не может нагрузить многоядерный проц/многопроцессорную машинку. именно поэтому 4-голового процессора хватит на десяток пользователей

именно что при прочих равных. это я, в общем, к тому, что

проблема не только в скорости сети (которая имеет весьма разную скорость, у нас к полке было 50ГБит, которые засирались полностью. такую скорость не всякий локальный хард даст при таком количестве обращений), но и именно в том, как ос на файловом сервере отрабатывает совместный доступ к файлу. поэтому nas будет шустрее windows server.

конечно, см. выше

да я не против. просто по ходу дискуссии у вас мнение как-то меняется в правильную сторону
начинали то с

да, предупредили перед этим, что через сеть медленнее. но уж если такое рекомендуете, то предупреждайте, что windows в такой ситуации - это убийство производительности на втором пользователе.

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

Не понял. А что мне надо было обосновать? С процитированным утверждением я согласен. Я что где то написал, что количество памяти потребляемое процессом 1С зависит от того на рабочей станции он запущен или в терминальной сессии? Где?

Список, похоже спор уже идет ради спора. Жаль не пятница. Снова повторю - весь сыр-бор по-моему пошел из за фразы:

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

Ок. давайте попробуем так:
Утверждение 1:

Утверждение 2:

С каким из этих утверждений по отдельности вы несогласны?

Да без проблем. Не имею абсолютно никаких намерений цепляться к словам и разводить флейм.

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

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

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

ну что, пойдемка-покуримка

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

тут все очень просто. начиная со второго процесса в память не грузятся dll, а это около 100Mb
ну дополнительные плюшки, связанные с отсутствием передачи данных по сети и прелестями протокола smb, если используется он (а это 99,9% файловых баз по сети)

Вот думаю, устроить дискуссию по этому поводу сейчас или таки дотянуть до пятницы..

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

Ну и вот, собственно что хотел сказать то:
В частном случае - оно так и есть. Но есть также один нюанс, поскольку если бы все было так просто, то у нас и сам модуль 1Cv8.exe занимал бы на терминальном сервере 500 мб на всех. На терминальном сервере действительно при запуске программы фактически в память подгружается один ее экземпляр, все последующие экземпляры просто работают с ссылкой на первый (хотя при этом каждый из них работает в собственном адресном пространстве, и думает что работает со своей копией). Но это справедливо до тех пор, пока процессу не потребуется произвести запись в ту область памяти, которую он занимает. И вот как только он это делает, для него уже сразу подгружается в память отдельный его экземпляр. Таким образом предсказать то, что мы сэкономим на запуске каждого процесса постоянный размер памяти - думаю невозможно.
Как то так..

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

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

неа, у каждого процесса всегда свое собственное адресное пространство, не пересекающееся с другими. в это адресное пространства просто отображаются страницы с исполняемым кодом и данными dll. причем запись в эти страницы приводит к тем самым падениям программ с сообщением memory cannot be write и предложением послать кляузу в микрософт.
любые данные на страницах dll - read only
раньше был злобный хак, позволяющий запустить код на страницах, помеченных как данные, но теперь для этого придется полезть в настройки системы и вырубить DEP, потому как раньше этим хаком активно пользовалась всякая мутирующая малварь

когда пользователей 200 - стоит начинать думать
особенно учитывая, что больше 2Gb процесс 1с употребить не в состоянии (клиент)