1C наотрез отказывается после 1 Гб видеть ECC память на non-ECC плате ASUS P5LD2-VM DH. Установлено DDR2-533 512МБх4 модуля Kingstone на non-ECC плате (временно поставили обычную персоналку в качестве сервера). Другие приложения (терминал, отдельные файловые копии 1С) работают и после 1 ГБ памяти, а когда сетевая версия 1С 8, и большой отчет - после того, как процесс занимает 600-700 Мб ОЗУ, начинает кричать "Не хватает памяти!". А нормально работает, если было занято перед началом проведения 200-300 Мб. Т.е. при оценке перед проведением огромных отчетов 1С убеждается, что все "убирается" в свободную память и начинает работать. Если будут подключаться в это время другие пользователи, то может и не завершить проведение (идет 30-60 минут), и вывалиться опять по причине нехватки памяти.
Подозрение - что не-ECC плата и большие задержки ECC памяти не нравятся 1Сv8, и она работате только с двумя (вместо 4х) банками (т.е. с только одной парой планок в 2-канальном режиме).
1С не хочет использовать ECC память на не-ECC плате
Модераторы: Trinity admin`s, Free-lance moderator`s
В том и дело, что при загрузке в память РАЗНЫХ процессов (сессия терминала, другая локальная копия того же 1С , и прочая) память заполняется (я забивал до 1,2-1,4 Гб), и никто не ругался.a_shats писал(а):Эээээ, а при чем тут 1С ? Приложение может получить ровно столько ОЗУ, сколько ей даст ОС :D Ну то есть - если ОС ОЗУ видит, то приложение его получить может.
У Вас никакие "твикеры" в реестре не порылись ?
А вот сетевая 1С растет-растет (единым процессом), доходит до отметки 700 Мб, маленькие документы - проводятся без проблем, а вот большие - тут же выводит "Не хватает столько-то памяти на сервере!". Причем не хватает каких-то 300-400 Мб максимум (50 Мб, 100 Мб). Такое бывает, когда действительно вся память занята. Но тут-то вроде бы есть, и много.
ОС установлена с нуля, никаких "настроек" к ней не применялось - все по умолчанию Windows Server SE 2003.
Вот и сейчас SysInfo-программа пишет: доступно всего памяти - 2039 Мб
занято - 839 Мб. Хотя Диспетчер показывает занято всего 631 Мб.
Ну это можно списать на всякие "системные нужды". Но почему 1С упорно не хочет жевать другой гигабайт памяти?
Несмотря на недоумение специалистов проблема решилась вытаскиванием серверных модулей по 512 МБ с ECC-коррекцией и установкой 2-х обычных DIMM DDR2-667 по 1 ГБ (двухканальный режим).
Теперь 1С ест столько, сколько ей надо - 1,2 ГБ.
В таких случаях остается только развести руками и констатировать: факт остается фактом.
Андрей, спасибо за помощь.
Теперь 1С ест столько, сколько ей надо - 1,2 ГБ.
В таких случаях остается только развести руками и констатировать: факт остается фактом.
Андрей, спасибо за помощь.
О-о-о-о, устройство ОС тут думаю ни при чем 
(это как я объявление видел: торговой фирме требуется администратор для конфигурирования 1С, знание Windows на уровне программиста)
Как мне видится - все проще и на уровне железа.
Хотелось бы прояснить вопрос - слышал, что 1С чувствительна к латентности памяти (а у ECC DDR она чуть не 2 раза выше, чем у обычной DDR2), а также узнать о стабильности работы ECC-памяти на non-EСС плате.
(это как я объявление видел: торговой фирме требуется администратор для конфигурирования 1С, знание Windows на уровне программиста
)Как мне видится - все проще и на уровне железа.
Хотелось бы прояснить вопрос - слышал, что 1С чувствительна к латентности памяти (а у ECC DDR она чуть не 2 раза выше, чем у обычной DDR2), а также узнать о стабильности работы ECC-памяти на non-EСС плате.
Объем выделенной задаче виртуальной памяти и физическая организация модулей памяти между собой никак не связаны, при интенсивной работе вирт. память задачи как правило будет разбросана по всей физической памяти.
Так что здесь "устройство ОС" очень даже при чем
Можно предположить, что 1с запрашивала большой кусок непрерывной памяти, а система его не смогла выделить из-за фрагментации. Откуда-то всплыло "ощущение", что система может сбоящие блоки памяти исключать из работы, и, чисто теоретически, это может привести к неустранимой фрагментации... но откуда это... и относится ли это вообще к винде...
В любом случае, это было бы отражено в логах.
Так что здесь "устройство ОС" очень даже при чем
Можно предположить, что 1с запрашивала большой кусок непрерывной памяти, а система его не смогла выделить из-за фрагментации. Откуда-то всплыло "ощущение", что система может сбоящие блоки памяти исключать из работы, и, чисто теоретически, это может привести к неустранимой фрагментации... но откуда это... и относится ли это вообще к винде...
В любом случае, это было бы отражено в логах.насчет латентности - 1с может и чувствительна, но это значит, что в синтетических тестах вы увидите падение производительности максимум на единицы процентов. с работоспособностью оно никак не связано.
ps: да и слухи о влиянии латентности похоже преувеличены. woodcrest в 1с показывает результаты хоть и немного, но стабильно лучше одночастотного athlon. то есть новое ядро intel + большой кэш + широкая шина к памяти более, чем компенсируют latency fbdimm (а latency там существенно больше обычной ddr2)
ps: да и слухи о влиянии латентности похоже преувеличены. woodcrest в 1с показывает результаты хоть и немного, но стабильно лучше одночастотного athlon. то есть новое ядро intel + большой кэш + широкая шина к памяти более, чем компенсируют latency fbdimm (а latency там существенно больше обычной ddr2)
Да нет вроде. Запихнул её обратно в сервак - контроллер домена, - где она и была первоначально...edo писал(а): может быть просто память битая была?
Насчет битых блоков - теория интересная, но тут получается целый гиг в битых оказывается...
Я больше склоняюсь к тому, что 1С (несмотря на то, что винда видела оба гига) работала только с двумя планками, объединенными в двухканальном режиме. А остальные две планки - игнорировала. Тут эта теория соприкасается с тем, что 1С действительно часто (когда большие запросы - гиганские, можно сказать, как у нас) требует предоставление НЕПРЕРЫВНОЙ памяти в больших объемах для своих нужд, а не получив таковой (например. по причине разрыва адресного пространства, скажем), вместо разбивки своих данных и нормальной работы вываливается. Вроде как "все, или ничего!".
неожиданное продолжение темы
как я уже говорил, те 4 планки Kingston воткнул в контроллер домена. Нагнал до 800 Мб занимаемой памяти (ну всякими там терминалами и прочим). Запустил приложение, которому тоже надо непрерывную память (потому как обновляется в реальном времени) - удаленный десктоп. В какой-то момент данный процесс занял 300 Мб - и сервер завис! Перезагрузка рулит. И опять - переход на размер больше одного Гб, те же планки.
Все 4 планки - ВРОДЕ БЫ одинаковые (тайминги, объем, производитель). Подробнее - могу предоставить характеристики.
Свою версию о несовместимости ECC-памяти и non-ECC платы беру обратно - похоже, это такая причудливая память, и только она.
Выдвигаю тогда новое (бредовое за неимением пока никаких других вариантов и мнений, хоть отчасти объясняющих происходящее) предположение.
Господа, а не кроется ли причина в том, что ECC-коррекция не может правильно сработать при переходе на другие 2 банка?
Т.е. приложение запрашивает непрерывную память, а она физически получается только как часть из 1-го набора банков (двухканальных 1 и 2) и часть - из 2-го (двухканальных 3 и 4). Внутри каждого набора планки работают синхронно (двухнальный режим), а потому и непроисходит обрыва.
Может, для ECC здесь барьер (переход из 1 Гб во второй), и происходит обрыв единого адресного пространства? И тогда 1С - кричит о нехватке, а другое приложение без проверки - просто зависает.
Тогда получается, что если все четыре планки будут работать не в двухканальном режиме, то размер, занимаемый одним приложением (именно одним динамическим процессом!) будет ограничен размером планки? это только мысли вслух - очеведное-невероятное.
Что у нас вообще за чудеса с этой памятью?
как я уже говорил, те 4 планки Kingston воткнул в контроллер домена. Нагнал до 800 Мб занимаемой памяти (ну всякими там терминалами и прочим). Запустил приложение, которому тоже надо непрерывную память (потому как обновляется в реальном времени) - удаленный десктоп. В какой-то момент данный процесс занял 300 Мб - и сервер завис! Перезагрузка рулит. И опять - переход на размер больше одного Гб, те же планки.
Все 4 планки - ВРОДЕ БЫ одинаковые (тайминги, объем, производитель). Подробнее - могу предоставить характеристики.
Свою версию о несовместимости ECC-памяти и non-ECC платы беру обратно - похоже, это такая причудливая память, и только она.
Выдвигаю тогда новое (бредовое за неимением пока никаких других вариантов и мнений, хоть отчасти объясняющих происходящее) предположение.
Господа, а не кроется ли причина в том, что ECC-коррекция не может правильно сработать при переходе на другие 2 банка?
Т.е. приложение запрашивает непрерывную память, а она физически получается только как часть из 1-го набора банков (двухканальных 1 и 2) и часть - из 2-го (двухканальных 3 и 4). Внутри каждого набора планки работают синхронно (двухнальный режим), а потому и непроисходит обрыва.
Может, для ECC здесь барьер (переход из 1 Гб во второй), и происходит обрыв единого адресного пространства? И тогда 1С - кричит о нехватке, а другое приложение без проверки - просто зависает.
Тогда получается, что если все четыре планки будут работать не в двухканальном режиме, то размер, занимаемый одним приложением (именно одним динамическим процессом!) будет ограничен размером планки? это только мысли вслух - очеведное-невероятное.
Что у нас вообще за чудеса с этой памятью?
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 20 гостей