сколько памяти надо под терминал?
Модераторы: Trinity admin`s, Free-lance moderator`s
сколько памяти надо под терминал?
дано:
- сервер с гигабайтом памяти, порядка 20 одновременных сеансов, база около 8Гб.
ошибка вкралась - сервер с двумя гигабайтами памяти
вопросы:
- как оценить достаточность текущей конфигурации? (я так понимаю смотреть "Обмен страниц/сек (Pages/sec)" в perfmon - какие значения нормальны?)
- насколько эффективно использет 1с (или windows) память для кеширования? стоит ли иметь память по объему соизмеримой с размером базы? (при текущих ценах на память реально собрать и сервер с 16Gb)
- сервер с гигабайтом памяти, порядка 20 одновременных сеансов, база около 8Гб.
ошибка вкралась - сервер с двумя гигабайтами памяти
вопросы:
- как оценить достаточность текущей конфигурации? (я так понимаю смотреть "Обмен страниц/сек (Pages/sec)" в perfmon - какие значения нормальны?)
- насколько эффективно использет 1с (или windows) память для кеширования? стоит ли иметь память по объему соизмеримой с размером базы? (при текущих ценах на память реально собрать и сервер с 16Gb)
Последний раз редактировалось edo 15 фев 2006, 12:09, всего редактировалось 1 раз.
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
в среднем меньше 0.1 со скачками до 0.5 ;)Stranger03 писал(а):Мда, 8-мь гигов ДБФ?
Надо посмотреть среднюю длину очереди к дискам,
порядка 4% от 3-х гигового своп-файла. хотя это не критично совершенно - понятно что памяти должно хватать, чтобы система не свопилась (она и не свопится), вопрос в том, чтобы эффективно кешировать базу данных.Stranger03 писал(а):использование файла подкачки,
мне вот какая мысль пришла в голову - операции записи не кэшируются (1с не велит), поэтому изменение объема памяти должно влиять на количество операций чтения в секунду, не меняя количества операций записи.
так вот у меня при нормальной нагрузке присутствуют практически только запросы на запись, из чего я сделал вывод что памяти достаточно. единственное исключение - отчеты - 8 гигов базы никак не помещаются в 2 гига памяти, но:
- на очередь дисков это никак не влияет;
- количество обращений к диску - порядка 100/с, когда в iometer на database pattern при q=1 этот массив выдает около 200;
- время формирования отчета за небольшой период в первый раз (данные читаются с диска) и во второй раз (данные берутся из кеша) практически одинаковое.
конечно же 100% ;)Stranger03 писал(а):загрузку процессоров
я знаю, что у меня сейчас всё уперлось в процессоры - поэтому выбираю новый сервер и хочу определиться с требованиями к нему.
я сделал вывод, что и памяти и дисков у меня достачно - поэтому по ним буду выбирать конфигурацию просто не хуже, чем сейчас.
почему? ;)Stranger03 писал(а):ИМХО, вам все-таки с таким объемом баз надо думать по переходу на SQL.
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
С какой это стати 1С не велит кешировать запросы записи на диск? Это управляется двумя вещами:edo писал(а):мне вот какая мысль пришла в голову - операции записи не кэшируются (1с не велит), поэтому изменение объема памяти должно влиять на количество операций чтения в секунду, не меняя количества операций записи.
1. драйвером контроллера. в случае если на физическом диске стоит AD, кеширование записи на такой диск блокируются драйвером ОС.
2. политиками самого контроллера Write Back/ Write True
1С работает на уровне приложения и к политикам записи не имеет абсолютно никакого отношения.
Это может говорить еще и о том, что тормозом являются процессоры например. Если их увеличить, акцент очень даже легко может перейти в память или диски.так вот у меня при нормальной нагрузке присутствуют практически только запросы на запись, из чего я сделал вывод что памяти достаточно. единственное исключение - отчеты - 8 гигов базы никак не помещаются в 2 гига памяти, но:
- на очередь дисков это никак не влияет;
Я честно говоря редко встречал ДБФ базы размером больше 2-х гигов. Как правило из-за ограничений на программном уровне такого рода базы вызывали либо жестокие тормоза, либо серьезные проблемы с целостностью баз. SQL при таком размере баз вам как минимум облегчит поиск по базе, плюс надежность выше, чем у дбф. Хотя здесь могу и ошибаться, не очень большой знаток SQL. Андрюха Шац поправит, .почему?Stranger03 писал(а):ИМХО, вам все-таки с таким объемом баз надо думать по переходу на SQL.
1c рассчитана на многопользовательскую работу и поэтому все изменения в dbf (и cdx) файлах для операционки помечаются как требующие немедленной записи на диск. контроллер (особенно raid c bbu) может отложить запись - но операционка (и 1с соответственно) будут думать, что данные записаны.Stranger03 писал(а):С какой это стати 1С не велит кешировать запросы записи на диск? Это управляется двумя вещами:edo писал(а):мне вот какая мысль пришла в голову - операции записи не кэшируются (1с не велит), поэтому изменение объема памяти должно влиять на количество операций чтения в секунду, не меняя количества операций записи.
1. драйвером контроллера. в случае если на физическом диске стоит AD, кеширование записи на такой диск блокируются драйвером ОС.
2. политиками самого контроллера Write Back/ Write True
1С работает на уровне приложения и к политикам записи не имеет абсолютно никакого отношения.
как точно это реализовано - я не могу утверждать, в юниксах это или fsync после записи или флаг O_SYNC при открытии или ещё как (postgresql например предлагает 4 метода на выбор). все бд так поступают ;)
при терминальной работе переиндексация - вещь нечастая (хотя мы делаем автоматическую переиндексацию раз в сутки).a_shats писал(а):На самом деле, SQL по определению медленнее. Но: есть такое слово на dbf страшное - "переиндексация": вот на SQL ея и не будет совсем :)
меня мучает другой вопрос - вполне возможно, что sql масштибируется для больших баз лучше dbf (то есть грубо говоря на базе в 100 метров dbf быстрее, на базе в 100 гигов sql быстрее). проверить этого сам к сожалению не могу
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
SQL по определению не может быть быстрее dbf, просто в силу того, что dbf - это плоские данные безо всяческих накладных расходов.
Другое дело, что поддержание целостности 100 ГБ плоских таблиц - мягко говоря, та еще задача А блокировки (таблиц целиком) на количестве пользователей в районе сотни - просто кошмар (SQL сам по себе блокирует только изменяемые строки). Но у 1С собственный механизм блокировок.
Другое дело, что поддержание целостности 100 ГБ плоских таблиц - мягко говоря, та еще задача А блокировки (таблиц целиком) на количестве пользователей в районе сотни - просто кошмар (SQL сам по себе блокирует только изменяемые строки). Но у 1С собственный механизм блокировок.
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Я что не понимаю, мы ведем речь про 1C SQL???? Вы никогда не встречали битых dbf файлов во время отключения питания на сервере? Вам крупно повезло.edo писал(а):1c рассчитана на многопользовательскую работу и поэтому все изменения в dbf (и cdx) файлах для операционки помечаются как требующие немедленной записи на диск. контроллер (особенно raid c bbu) может отложить запись - но операционка (и 1с соответственно) будут думать, что данные записаны.
как точно это реализовано - я не могу утверждать, в юниксах это или fsync после записи или флаг O_SYNC при открытии или ещё как (postgresql например предлагает 4 метода на выбор). все бд так поступают
Лет 15-ть назад я только ради восстановления 2-х баз бухгалтерии написал прогу для пересобирания файла на низком уровне. Где-то эта прога должна валяться в просторах интернета на FOX-ых сайтах.
Как бы не была хороша 1С DBF, как бы она не блокировала базы или не открывала их с флагами, она не может заставить операционную систему или драйвер немедленно писать на диск. Если это действительно так - покажите мне исходники, где это написано в оригинале?
какое отключение питания на сервере?!?Stranger03 писал(а):Я что не понимаю, мы ведем речь про 1C SQL???? Вы никогда не встречали битых dbf файлов во время отключения питания на сервере? Вам крупно повезло.
ну где я возьму исходники 1с?Stranger03 писал(а):Как бы не была хороша 1С DBF, как бы она не блокировала базы или не открывала их с флагами, она не может заставить операционную систему или драйвер немедленно писать на диск. Если это действительно так - покажите мне исходники, где это написано в оригинале?
но сами подумайте - работает 1с по сети, началась транзакция. для этого она делает записи в специальный файл. если изменения в этом файле будут кешироваться на запись на компьютере, который начал транзакцию или же на чтение на других компьютерах, то никто эту транзакцию не увидит.
работает же 1с по сети или же локально в терминале - она не знает.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 20 гостей