сколько памяти надо под терминал?

edo · Сообщение **edo** » 14 фев 2006, 19:41

дано:
- сервер с гигабайтом памяти, порядка 20 одновременных сеансов, база около 8Гб.
ошибка вкралась - сервер с двумя гигабайтами памяти

вопросы:
- как оценить достаточность текущей конфигурации? (я так понимаю смотреть "Обмен страниц/сек (Pages/sec)" в perfmon - какие значения нормальны?)
- насколько эффективно использет 1с (или windows) память для кеширования? стоит ли иметь память по объему соизмеримой с размером базы? (при текущих ценах на память реально собрать и сервер с 16Gb)

Сообщение gs » 14 фев 2006, 19:58

Так у Вас терминал или база + терминал?

edo · Сообщение **edo** » 14 фев 2006, 20:04

под базой имеется в виду sql? нет, всё на dbf крутится

Сообщение gs » 14 фев 2006, 20:11

ВАУУУ! Как все плохо! Дождитесь завтра Шаца - он наш штатный борец с 1С.

Сообщение **Stranger03** » 15 фев 2006, 10:56

Мда, 8-мь гигов ДБФ?
Надо посмотреть среднюю длину очереди к дискам, использование файла подкачки, загрузку процессоров, использование памяти. Точно по параметрам подскажет Андрей. ИМХО, вам все-таки с таким объемом баз надо думать по переходу на SQL.

edo · Сообщение **edo** » 15 фев 2006, 12:06

Stranger03 писал(а):Мда, 8-мь гигов ДБФ?
Надо посмотреть среднюю длину очереди к дискам,

в среднем меньше 0.1 со скачками до 0.5 ;)

Stranger03 писал(а):использование файла подкачки,

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

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

так вот у меня при нормальной нагрузке присутствуют практически только запросы на запись, из чего я сделал вывод что памяти достаточно. единственное исключение - отчеты - 8 гигов базы никак не помещаются в 2 гига памяти, но:
- на очередь дисков это никак не влияет;
- количество обращений к диску - порядка 100/с, когда в iometer на database pattern при q=1 этот массив выдает около 200;
- время формирования отчета за небольшой период в первый раз (данные читаются с диска) и во второй раз (данные берутся из кеша) практически одинаковое.

Stranger03 писал(а):загрузку процессоров

конечно же 100% ;)
я знаю, что у меня сейчас всё уперлось в процессоры - поэтому выбираю новый сервер и хочу определиться с требованиями к нему.

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

Stranger03 писал(а):ИМХО, вам все-таки с таким объемом баз надо думать по переходу на SQL.

почему? ;)

edo · Сообщение **edo** » 15 фев 2006, 16:05

для справки - сколько будут стоить:
- 4xOpteron 870, 6x15k дисков (минимальной емкости), 4Gb RAM;
- 2xOpteron 275, 4x15k дисков (минимальной емкости), 2Gb RAM.

a_shats · Сообщение **a_shats** » 15 фев 2006, 16:46

Цены отправлены на мыло.
Вопрос: у Вас остатки свернуты (вся эта база в 8 ГБайт активна) или это база за несколько лет ?

edo · Сообщение **edo** » 15 фев 2006, 17:01

это база где-то за полтора года

Сообщение **Stranger03** » 16 фев 2006, 17:07

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

С какой это стати 1С не велит кешировать запросы записи на диск? Это управляется двумя вещами:
1. драйвером контроллера. в случае если на физическом диске стоит AD, кеширование записи на такой диск блокируются драйвером ОС.
2. политиками самого контроллера Write Back/ Write True

1С работает на уровне приложения и к политикам записи не имеет абсолютно никакого отношения.

так вот у меня при нормальной нагрузке присутствуют практически только запросы на запись, из чего я сделал вывод что памяти достаточно. единственное исключение - отчеты - 8 гигов базы никак не помещаются в 2 гига памяти, но:
- на очередь дисков это никак не влияет;

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

Stranger03 писал(а):ИМХО, вам все-таки с таким объемом баз надо думать по переходу на SQL.
почему?

Я честно говоря редко встречал ДБФ базы размером больше 2-х гигов. Как правило из-за ограничений на программном уровне такого рода базы вызывали либо жестокие тормоза, либо серьезные проблемы с целостностью баз. SQL при таком размере баз вам как минимум облегчит поиск по базе, плюс надежность выше, чем у дбф. Хотя здесь могу и ошибаться, не очень большой знаток SQL. Андрюха Шац поправит,

.

a_shats · Сообщение **a_shats** » 16 фев 2006, 17:21

На самом деле, SQL по определению медленнее. Но: есть такое слово на dbf страшное - "переиндексация": вот на SQL ея и не будет совсем

edo · Сообщение **edo** » 16 фев 2006, 19:50

Stranger03 писал(а):
edo писал(а):мне вот какая мысль пришла в голову - операции записи не кэшируются (1с не велит), поэтому изменение объема памяти должно влиять на количество операций чтения в секунду, не меняя количества операций записи.
С какой это стати 1С не велит кешировать запросы записи на диск? Это управляется двумя вещами:
1. драйвером контроллера. в случае если на физическом диске стоит AD, кеширование записи на такой диск блокируются драйвером ОС.
2. политиками самого контроллера Write Back/ Write True

1С работает на уровне приложения и к политикам записи не имеет абсолютно никакого отношения.

1c рассчитана на многопользовательскую работу и поэтому все изменения в dbf (и cdx) файлах для операционки помечаются как требующие немедленной записи на диск. контроллер (особенно raid c bbu) может отложить запись - но операционка (и 1с соответственно) будут думать, что данные записаны.

как точно это реализовано - я не могу утверждать, в юниксах это или fsync после записи или флаг O_SYNC при открытии или ещё как (postgresql например предлагает 4 метода на выбор). все бд так поступают ;)

a_shats писал(а):На самом деле, SQL по определению медленнее. Но: есть такое слово на dbf страшное - "переиндексация": вот на SQL ея и не будет совсем :)

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

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

a_shats · Сообщение **a_shats** » 17 фев 2006, 15:07

SQL по определению не может быть быстрее dbf, просто в силу того, что dbf - это плоские данные безо всяческих накладных расходов.
Другое дело, что поддержание целостности 100 ГБ плоских таблиц - мягко говоря, та еще задача

А блокировки (таблиц целиком) на количестве пользователей в районе сотни - просто кошмар (SQL сам по себе блокирует только изменяемые строки). Но у 1С собственный механизм блокировок.

Сообщение **Stranger03** » 17 фев 2006, 16:34

edo писал(а):1c рассчитана на многопользовательскую работу и поэтому все изменения в dbf (и cdx) файлах для операционки помечаются как требующие немедленной записи на диск. контроллер (особенно raid c bbu) может отложить запись - но операционка (и 1с соответственно) будут думать, что данные записаны.

как точно это реализовано - я не могу утверждать, в юниксах это или fsync после записи или флаг O_SYNC при открытии или ещё как (postgresql например предлагает 4 метода на выбор). все бд так поступают

Я что не понимаю, мы ведем речь про 1C SQL???? Вы никогда не встречали битых dbf файлов во время отключения питания на сервере? Вам крупно повезло.
Лет 15-ть назад я только ради восстановления 2-х баз бухгалтерии написал прогу для пересобирания файла на низком уровне. Где-то эта прога должна валяться в просторах интернета на FOX-ых сайтах.
Как бы не была хороша 1С DBF, как бы она не блокировала базы или не открывала их с флагами, она не может заставить операционную систему или драйвер немедленно писать на диск. Если это действительно так - покажите мне исходники, где это написано в оригинале?

edo · Сообщение **edo** » 20 фев 2006, 19:24

Stranger03 писал(а):Я что не понимаю, мы ведем речь про 1C SQL???? Вы никогда не встречали битых dbf файлов во время отключения питания на сервере? Вам крупно повезло.

какое отключение питания на сервере?!?

Stranger03 писал(а):Как бы не была хороша 1С DBF, как бы она не блокировала базы или не открывала их с флагами, она не может заставить операционную систему или драйвер немедленно писать на диск. Если это действительно так - покажите мне исходники, где это написано в оригинале?

ну где я возьму исходники 1с?

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

сколько памяти надо под терминал?

сколько памяти надо под терминал?

Кто сейчас на конференции