Файловые БД на сжатом HDD
Доброго времени суток.
Передали конторку, стоит нормальный сервер ( по меркам 2005-2007гг).
Дисковая система (Зеркалирование выполнено средствами WinSrv2k3):
array_1 (Raid1 из HDD 2*250Gb)
array_2 (Raid1 из HDD 2*1Tb)
array_1 разбит на 2 раздела:
0. Система
1. Данные (пользовательские папки, базы 1С)
На array_2 хранятся копии и т.п.
Раздел под данные (array_1.1) сжат, видимо была нехватка места.
Собственно вопрос, влияет ли сжатие раздела (NTFS) на скорость работы с базами?
Оставлять как есть, или снимать сжатие?
Спасибо.
Передали конторку, стоит нормальный сервер ( по меркам 2005-2007гг).
Дисковая система (Зеркалирование выполнено средствами WinSrv2k3):
array_1 (Raid1 из HDD 2*250Gb)
array_2 (Raid1 из HDD 2*1Tb)
array_1 разбит на 2 раздела:
0. Система
1. Данные (пользовательские папки, базы 1С)
На array_2 хранятся копии и т.п.
Раздел под данные (array_1.1) сжат, видимо была нехватка места.
Собственно вопрос, влияет ли сжатие раздела (NTFS) на скорость работы с базами?
Оставлять как есть, или снимать сжатие?
Спасибо.
По теме из базы знаний
Ответы
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(1) arshanskiyav, по-моему, все очевидно: если сжатие/декомпрессия данных осуществляются программно, то они занимают процессорное время, т.е. совершенно не влиять не могут.
Другое дело - насколько существенно такое влияние? Если работа с базой осуществляется в режиме файл-сервера, то замедление вряд ли заметно: в этом случае обычно самое узкое место - сеть, а процессор большую часть времени простаивает.
А вот в терминале, да еще и с большим количеством пользователей отвлечение процессора (особенно единственного) на сжатие может и ощущаться.
Поэтому приведенной вами информации явно недостаточно для корректного ответа.
Другое дело - насколько существенно такое влияние? Если работа с базой осуществляется в режиме файл-сервера, то замедление вряд ли заметно: в этом случае обычно самое узкое место - сеть, а процессор большую часть времени простаивает.
А вот в терминале, да еще и с большим количеством пользователей отвлечение процессора (особенно единственного) на сжатие может и ощущаться.
Поэтому приведенной вами информации явно недостаточно для корректного ответа.
(2) Cooler, Мне показалось достаточно.
Сервер терминальный, вся работа с 1С (8.2 УПП) осуществляется на нем. Пользователей было 30, сейчас 8-10.
Процессор Xeon 5130 (2 ядра по 2Ггц)
ОЗУ DDR2 10Гб
Сжатие осуществляется средствами самой ОС, поэтому не могу с уверенностью сказать программно или аппаратно.
В этот МоментВремени 5 пользователей работают в 1С, на процессор нагрузка 1-5%.
Иногда пользователь отмечает "подтормаживание", окно 1С (при попытке записи/проведения, вызов формы выбора и т.п.) может зависнуть (максимально 23 минуты).
В будущем сервер будут менять, но так как будущее неопределенно, хотелось бы понять даст ли результат отключение функции.
Сервер терминальный, вся работа с 1С (8.2 УПП) осуществляется на нем. Пользователей было 30, сейчас 8-10.
Процессор Xeon 5130 (2 ядра по 2Ггц)
ОЗУ DDR2 10Гб
Сжатие осуществляется средствами самой ОС, поэтому не могу с уверенностью сказать программно или аппаратно.
В этот МоментВремени 5 пользователей работают в 1С, на процессор нагрузка 1-5%.
Иногда пользователь отмечает "подтормаживание", окно 1С (при попытке записи/проведения, вызов формы выбора и т.п.) может зависнуть (максимально 23 минуты).
В будущем сервер будут менять, но так как будущее неопределенно, хотелось бы понять даст ли результат отключение функции.
(3) arshanskiyav,
Поэтому избавление от сжатия по крайней мере не ухудшит ситуацию. Для очистки совести можете помониторить производительность (perfmon.exe), особенно во время подвисаний, и посмотреть - что именно в такие моменты загружено на 100% - процессор, диск или, может, обмен с ОЗУ?
Потом думать и принимать решение.
Сервер терминальный, вся работа с 1С (8.2 УПП) осуществляется на нем. Пользователей было 30, сейчас 8-10.
Процессор Xeon 5130 (2 ядра по 2Ггц)
Один небыстрый процессор обсчитывает 10 экземпляров 1С? Наверняка периодически захлебывается, да еще и на обработку сжатия отвлекается.
Процессор Xeon 5130 (2 ядра по 2Ггц)
Сжатие осуществляется средствами самой ОС, поэтому не могу с уверенностью сказать программно или аппаратно.
ОС - это то, что исполняется программно, центральным процессором, так что можете не сомневаться.
Поэтому избавление от сжатия по крайней мере не ухудшит ситуацию. Для очистки совести можете помониторить производительность (perfmon.exe), особенно во время подвисаний, и посмотреть - что именно в такие моменты загружено на 100% - процессор, диск или, может, обмен с ОЗУ?
Потом думать и принимать решение.
(5) Cooler,
Картина на скриншоте появляется редко (но и здесь, рубеж в 50% процессора не пересечен):
В основном:
В Момент снятия показаний (оба скриншота) было запущено 9 экземпляров 1С. Правда чем там занимаются пользователи остается загадкой.
Базы меньше 1.5Гб сжаты в 2-4 раза, а которые больше примерно в 1.9 раза (с 2,5Гб до 1,5)
Один небыстрый процессор обсчитывает 10 экземпляров 1С? Наверняка периодически захлебывается, да еще и на обработку сжатия отвлекается.
Картина на скриншоте появляется редко (но и здесь, рубеж в 50% процессора не пересечен):
В основном:
В Момент снятия показаний (оба скриншота) было запущено 9 экземпляров 1С. Правда чем там занимаются пользователи остается загадкой.
Если соотношение два и более, то по моему опыту использования "сжатия", это даёт реальное ускорение в терминальном использовании приложений для файловых СУБД (приложение и СУБД на одном компьютере).
Базы меньше 1.5Гб сжаты в 2-4 раза, а которые больше примерно в 1.9 раза (с 2,5Гб до 1,5)
(7) arshanskiyav, если у вас там не 5 дисков. То у вас проблемы с дисковой подсистемой.
А база у вас крутится на:
двух шпенделях. Нормальная длинна очереди к диску должна быть не более 4-5. У вас проблемы. Не факт что от сжатия, может рейды отвратительные, что программный, что аппаратный. Интелловский хороший чип нужен. Можно что-то б/у купить.
А у вас
это фейл короче.
Ещё винты могут подыхать.
Это почти не повлияет на "тормоза". Я бы снял до кучи.
Зеркало ещё с его штрафом на запись...
и про сами винты ни слова. Может вы ожидаете хорошей производительности от десктопных винтов.
А база у вас крутится на:
array_1 (Raid1 из HDD 2*250Gb)
двух шпенделях. Нормальная длинна очереди к диску должна быть не более 4-5. У вас проблемы. Не факт что от сжатия, может рейды отвратительные, что программный, что аппаратный. Интелловский хороший чип нужен. Можно что-то б/у купить.
А у вас
Дисковая система (Зеркалирование выполнено средствами WinSrv2k3):
это фейл короче.
Ещё винты могут подыхать.
Собственно вопрос, влияет ли сжатие раздела (NTFS) на скорость работы с базами?
Оставлять как есть, или снимать сжатие?
Оставлять как есть, или снимать сжатие?
Это почти не повлияет на "тормоза". Я бы снял до кучи.
Зеркало ещё с его штрафом на запись...
и про сами винты ни слова. Может вы ожидаете хорошей производительности от десктопных винтов.
(9) arshanskiyav, (10) arshanskiyav,
Ок. Забудем про диски тогда.
2-3 минуты?
Ну...
Сымайте сжатие.
При таких вводных, про нулевую очередь к диску я что-то не верю. Пользователи в этот момент чай пили?
Иногда пользователь отмечает "подтормаживание", окно 1С (при попытке записи/проведения, вызов формы выбора и т.п.) может зависнуть (максимально 23 минуты).
Ок. Забудем про диски тогда.
2-3 минуты?
Ну...
Базы меньше 1.5Гб сжаты в 2-4 раза, а которые больше примерно в 1.9 раза (с 2,5Гб до 1,5)
Базы, вот как. Меняю своё мнение. Это действительно может быть виновато сжатие. Во время распаковки (открытия/ закрытия) какого-либо сжатого файла, 1С вполне себе окажется не в приоритете. Взять хотя-бы пользовательские файлы. Пользователь открыл эксель файл - диск напрягся: прочитать файл, расшифровать положив в кеш, зашифровать и схоронить на диск когда его закроют.
Сымайте сжатие.
При таких вводных, про нулевую очередь к диску я что-то не верю. Пользователи в этот момент чай пили?
(11) fzt, Мне тоже не верится, возможно я не правильно выбрал счетчики, но мне кажется правильно.
Сегодня зафиксировал завис файловой БД (3 экземпляра), уже не сжатая, вес общий 4Гб (1CD 2.6Гб).
Очередь максимум 5, а вот процент активности диска >200%.
Получается проблема точно не в сжатии.
Сегодня зафиксировал завис файловой БД (3 экземпляра), уже не сжатая, вес общий 4Гб (1CD 2.6Гб).
Очередь максимум 5, а вот процент активности диска >200%.
Получается проблема точно не в сжатии.
(1)
Андрей (arshanskiyav).
Посмотрите в "свойствах" файла 1Cv8.1CD его размер и сколько он занимает места на диске.
Если соотношение два и более, то по моему опыту использования "сжатия", это даёт реальное ускорение в терминальном использовании приложений для файловых СУБД (приложение и СУБД на одном компьютере). И не стоит беспокоиться по поводу "лишней" нагрузки на процессор самим сжатием. Она ничтожна по сравнению с остальными нагрузками процессора самой 1С-иной. А количество операций ввода-вывода (плюс улучшение системного кеширования) уменьшается. Про надежность - особый разговор. При использовании RAID средствами ОС надёжность низкая. И относительно этого - сжатие снижет её
чуть-чуть. ;-)
Андрей (arshanskiyav).
Посмотрите в "свойствах" файла 1Cv8.1CD его размер и сколько он занимает места на диске.
Если соотношение два и более, то по моему опыту использования "сжатия", это даёт реальное ускорение в терминальном использовании приложений для файловых СУБД (приложение и СУБД на одном компьютере). И не стоит беспокоиться по поводу "лишней" нагрузки на процессор самим сжатием. Она ничтожна по сравнению с остальными нагрузками процессора самой 1С-иной. А количество операций ввода-вывода (плюс улучшение системного кеширования) уменьшается. Про надежность - особый разговор. При использовании RAID средствами ОС надёжность низкая. И относительно этого - сжатие снижет её
чуть-чуть. ;-)
(1) arshanskiyav,
Чисто на будущее (если ещё интересно)
1. Зеркалирование средствами windows имеет дурную особенность - незаметно, чтобы оно ускоряло чтение распараллеливанием по дискам.
2. Делалась ли на диске оптимизация? Хорошая, качественная, как в mydefrag/jkdefrag?
3. Весь диск сжатый -> пользовательские профили тоже сжаты -> 1С тормозит ещё больше. Да и вообще, пользовательские профили (в плане данных 1С) нужно было выносить на второй массив.
Чисто на будущее (если ещё интересно)
1. Зеркалирование средствами windows имеет дурную особенность - незаметно, чтобы оно ускоряло чтение распараллеливанием по дискам.
2. Делалась ли на диске оптимизация? Хорошая, качественная, как в mydefrag/jkdefrag?
3. Весь диск сжатый -> пользовательские профили тоже сжаты -> 1С тормозит ещё больше. Да и вообще, пользовательские профили (в плане данных 1С) нужно было выносить на второй массив.
(28) Уфаныч,
Вы имеет ввиду полностью профиль перекинуть, или только папки 1С в профилях?
Если последнее, то как решаете задачу (чисто из любопытства)?
Не сильно понял предложение
пользовательские профили (в плане данных 1С) нужно было выносить на второй массив.
Вы имеет ввиду полностью профиль перекинуть, или только папки 1С в профилях?
Если последнее, то как решаете задачу (чисто из любопытства)?
Зеркалирование средствами windows имеет дурную особенность - незаметно, чтобы оно ускоряло чтение распараллеливанием по дискам.
Не сильно понял предложение
Решил отталкиваться от процента бездействия ЖД.
При запуске базы проседает до 3,8%.
Да, проблема в жестком диске (хотя СМАРТ показывает типа норм)
На скриншоте зафиксировано поведение жесткого диска (%простоя и %активности) при попытке получить отчет "Анализ заказов покупателей" за год.
Хм, странно.
Перенес базу на второй рейд (диски новее), та же фигня.
При запуске базы проседает до 3,8%.
Да, проблема в жестком диске (хотя СМАРТ показывает типа норм)
На скриншоте зафиксировано поведение жесткого диска (%простоя и %активности) при попытке получить отчет "Анализ заказов покупателей" за год.
Хм, странно.
Перенес базу на второй рейд (диски новее), та же фигня.
Сравнил процент простоя ЖД до и после сжатия папки с базой.
Папка (до/после): 4,44Гб/1,8Гб
1Cv8.1CD (до/после): 2,6Гб/1,45Гб
Операция выполнялась та же - вывод отчета о заказах за год.
На скриншоте зафиксировано - Запуск 1С, открытие базы, создание отчета, закрытие 1С
Как видно из скриншота, нагрузка на процессор чуть выше (процента на 3), время простоя больше на 7%, процент активности не превысил отметку 96%.
Папка (до/после): 4,44Гб/1,8Гб
1Cv8.1CD (до/после): 2,6Гб/1,45Гб
Операция выполнялась та же - вывод отчета о заказах за год.
На скриншоте зафиксировано - Запуск 1С, открытие базы, создание отчета, закрытие 1С
Как видно из скриншота, нагрузка на процессор чуть выше (процента на 3), время простоя больше на 7%, процент активности не превысил отметку 96%.
(14)
Андрей (arshanskiyav).
Ну, т.е. ответ на вопрос из (1) - почти не влияет. ;-)
Какой ещё вопрос? Если вопрос про "может зависнуть"(с). То, для начала, рекомендую поменять "местами" содержание разделов с базой и копии базы. И потом наблюдать на каких задачах "зависает".
Еще хочу обратить Ваше внимание, что сервер слабоват в части CPU-RAM даже для одной сессии 1С. А если ещё и ОС не x64. то это совсем не есть хорошо...
Андрей (arshanskiyav).
Ну, т.е. ответ на вопрос из (1) - почти не влияет. ;-)
Какой ещё вопрос? Если вопрос про "может зависнуть"(с). То, для начала, рекомендую поменять "местами" содержание разделов с базой и копии базы. И потом наблюдать на каких задачах "зависает".
Еще хочу обратить Ваше внимание, что сервер слабоват в части CPU-RAM даже для одной сессии 1С. А если ещё и ОС не x64. то это совсем не есть хорошо...
(15) hogik,
А на чем основано это предположение? (про рекомендации я знаю)
По факту, я не вижу предельной нагрузки на ресурсы.
Есть еще один момент. При закрытии 1с со сжатой базой, процесс висит еще продолжительное время, более 4 минут
ПыСы
Перенес базу на другую тачку и подключился к ней по сети, общее время выполнения той же последовательности операций меньше на минуты, т.е. почти в два раза. Но нагрузка на процессор почти все время 25% для одного экземпляра, здесь я согласен, для 3 сессий уже слабовата машинка.
Еще хочу обратить Ваше внимание, что сервер слабоват в части CPU-RAM даже для одной сессии 1С. А если ещё и ОС не x64. то это совсем не есть хорошо...
А на чем основано это предположение? (про рекомендации я знаю)
По факту, я не вижу предельной нагрузки на ресурсы.
Ну, т.е. ответ на вопрос из (1) - почти не влияет. ;-)
Есть еще один момент. При закрытии 1с со сжатой базой, процесс висит еще продолжительное время, более 4 минут
ПыСы
Перенес базу на другую тачку и подключился к ней по сети, общее время выполнения той же последовательности операций меньше на минуты, т.е. почти в два раза. Но нагрузка на процессор почти все время 25% для одного экземпляра, здесь я согласен, для 3 сессий уже слабовата машинка.
(16)
Андрей (arshanskiyav).
Какое предположение из двух? :-)
По обоим напишу:
1) При использовании 1С (особенной файловой версии) в терминальном режиме на первые места узких мест выходит CPU+RAM. Ваш сервер (применительно к 1С-продукту) является файл-сервером. А Вам нужна мощная рабочая станция. Т.е. быстрая связка CPU+RAM.
Вот, загляните сюда:
2) По своей сути HDD очень медленное устройство. И работает оно нормально только из-за использования всевозможных кэшей. В Win x64 системное кэширование работает значительно эффективней чем в 32-битных системах.
Проведите следующий "тест" - скопируйте большой (несколько гигабайт) файл в рамках одного HDD пару раз. Первый раз сразу после загрузки системы. Понаблюдайте за временем выполнения, миганием лампочки и звуком от диска. ;-) Дык, в системе х64 второе копирование пройдет "мгновенно" - будут выполняться только операции записи. И главное, что головки не будут позиционироваться в исходный файл и результирующий.
Теперь представьте, что происходит когда в Вашей системе на одном диске множество задач обращаются к файлам множества баз данных. Ну, хоть повторное чтение информации им облегчить надо. А наши задачи "грешат" многократным чтением одной и той же информации.
Я не могу это связать со сжатием. Думаю, что причина в другом. Проведите наблюдения на не сжатом диске. Отключите сжатие вообще. Я же не настаиваю на использовании сжатия. :-)
P.S.
По поводу работы по сети следует учитывать "эффект второго пользователя".
Вот, загляните сюда:
А про надежность/достоверность/исправность базы данных и говорить не приходится при работе по сети. Всё будет очень плохо...
Андрей (arshanskiyav).
А на чем основано это предположение?
Какое предположение из двух? :-)
По обоим напишу:
1) При использовании 1С (особенной файловой версии) в терминальном режиме на первые места узких мест выходит CPU+RAM. Ваш сервер (применительно к 1С-продукту) является файл-сервером. А Вам нужна мощная рабочая станция. Т.е. быстрая связка CPU+RAM.
Вот, загляните сюда:
2) По своей сути HDD очень медленное устройство. И работает оно нормально только из-за использования всевозможных кэшей. В Win x64 системное кэширование работает значительно эффективней чем в 32-битных системах.
Проведите следующий "тест" - скопируйте большой (несколько гигабайт) файл в рамках одного HDD пару раз. Первый раз сразу после загрузки системы. Понаблюдайте за временем выполнения, миганием лампочки и звуком от диска. ;-) Дык, в системе х64 второе копирование пройдет "мгновенно" - будут выполняться только операции записи. И главное, что головки не будут позиционироваться в исходный файл и результирующий.
Теперь представьте, что происходит когда в Вашей системе на одном диске множество задач обращаются к файлам множества баз данных. Ну, хоть повторное чтение информации им облегчить надо. А наши задачи "грешат" многократным чтением одной и той же информации.
При закрытии 1с со сжатой базой, процесс висит еще продолжительное время
Я не могу это связать со сжатием. Думаю, что причина в другом. Проведите наблюдения на не сжатом диске. Отключите сжатие вообще. Я же не настаиваю на использовании сжатия. :-)
P.S.
По поводу работы по сети следует учитывать "эффект второго пользователя".
Вот, загляните сюда:
А про надежность/достоверность/исправность базы данных и говорить не приходится при работе по сети. Всё будет очень плохо...
(15) hogik, Я прошу прощения, был не прав.
Как выяснилось проблема в очень низкой скорости чтения/записи. И как следствие минимальная нагрузка на процессор.
В связи с этим результаты сравнения сжатой/не сжатой базы выше нельзя назвать правильными/достоверными.
Спасибо.
Как выяснилось проблема в очень низкой скорости чтения/записи. И как следствие минимальная нагрузка на процессор.
В связи с этим результаты сравнения сжатой/не сжатой базы выше нельзя назвать правильными/достоверными.
Спасибо.
(17)
Андрей (arshanskiyav).
Я написал и "отправил" своё (19) сообщение до прочтения Вашего (17) сообщения.
А потом результат теста дисков меня очень сильно удивил.
Посмотрите на самих дисках наклейку - чего там написано про Advanced Format.
"Может как поддерживаться, так и не поддерживаться. Компания Seagate поставляет данные жесткие диски с размером сектора 4 КБ и 512 байт."(с)
Андрей (arshanskiyav).
Я написал и "отправил" своё (19) сообщение до прочтения Вашего (17) сообщения.
А потом результат теста дисков меня очень сильно удивил.
Посмотрите на самих дисках наклейку - чего там написано про Advanced Format.
"Может как поддерживаться, так и не поддерживаться. Компания Seagate поставляет данные жесткие диски с размером сектора 4 КБ и 512 байт."(с)
(17)
Андрей (arshanskiyav).
Данное тестирование не совсем точно отражает нашу жизнь с 1С-ами всякими. :-)
Вот, провел два теста:
Картинка RAM - это RAM диск, сжатие включено. Блеск результат. :-)
Картинка HDD - это HDD 2 Tb SATA 6Gb/s Western Digital RE < WD2000FYYZ > 3.5" 7200rpm 64Mb
Однако...
При сравнении времён выполнения различных задач в 1С 7.7/8.3 обнаруживается, что RAM диск уступает в скорости HDD диску. Особенно по чтению, т.к. для RAM диска отключено, как я понимаю, системное кэширование.
Андрей (arshanskiyav).
Данное тестирование не совсем точно отражает нашу жизнь с 1С-ами всякими. :-)
Вот, провел два теста:
Картинка RAM - это RAM диск, сжатие включено. Блеск результат. :-)
Картинка HDD - это HDD 2 Tb SATA 6Gb/s Western Digital RE < WD2000FYYZ > 3.5" 7200rpm 64Mb
Однако...
При сравнении времён выполнения различных задач в 1С 7.7/8.3 обнаруживается, что RAM диск уступает в скорости HDD диску. Особенно по чтению, т.к. для RAM диска отключено, как я понимаю, системное кэширование.
Прикрепленные файлы:
(21) hogik,
Другое дело, что работа с базой не ограничивается обращениями к ее папке - вполне возможно создание временных файлов, свопинг, для 1С 8 - обращения к кэшу пользователя и т.д.
Так что в зависимости от методики замеров результаты могут быть очень противоречивыми.
для RAM диска отключено, как я понимаю, системное кэширование
Кеширование RAM-диска - это нонсенс: ведь суть кэширования заключается в замене обращений к диску обращениями к ОЗУ (для ранее прочитанных областей), а тут все данные уже находятся в ОЗУ - ну какой может быть смысл в их кэшировании?
Другое дело, что работа с базой не ограничивается обращениями к ее папке - вполне возможно создание временных файлов, свопинг, для 1С 8 - обращения к кэшу пользователя и т.д.
Так что в зависимости от методики замеров результаты могут быть очень противоречивыми.
...
(17) arshanskiyav, меняй диски. Ставь несколько рейдов 10, или побольше дисков но в 10 рейде. НУ или SSD воткни, дорогой интеловский. Можно гибридный рейд HDD+SSD с дерьмодиском SSD. Контроллер должен быть аппаратный. Отдельно купленный. Да это дорого.
Если денег совсем жаба душит, воткни этим скупым дваждыплатам SSD и предупреди что будут только бэкапы ночные.
Подумай про увеличение ОЗУ и MsSQL. Этот сервер мог бы продолжить службу как сервер СУБД. При выносе с него терминальной нагрузки. Не на этих дисках разумеется.
(17) arshanskiyav, меняй диски. Ставь несколько рейдов 10, или побольше дисков но в 10 рейде. НУ или SSD воткни, дорогой интеловский. Можно гибридный рейд HDD+SSD с дерьмодиском SSD. Контроллер должен быть аппаратный. Отдельно купленный. Да это дорого.
Если денег совсем жаба душит, воткни этим скупым дваждыплатам SSD и предупреди что будут только бэкапы ночные.
Подумай про увеличение ОЗУ и MsSQL. Этот сервер мог бы продолжить службу как сервер СУБД. При выносе с него терминальной нагрузки. Не на этих дисках разумеется.
(24) fzt,
Прикол в том что стоит там сервак 1С (2-летней выдержки) с MSSQL, все как положено (E3-1245 v3, 16Гб ДДР3, 4 винта в 10 аппаратном Рэйде (в материнке)).
А основная рабочая база болтается на терминале в файле.
Пришел с пылесосом и SATA-шлейфами, 60 минут и показатели rw возросли в 3-6 раз. Правда все равно не дотягивает до соточки, чую проблема уже в ОС и старом железе (возможно там и не SATA II O_O).
В итоге перенес базу на сервер 1С.
Сейчас жду еще восьмигиговую планочку, на всякий случай.
Прикол в том что стоит там сервак 1С (2-летней выдержки) с MSSQL, все как положено (E3-1245 v3, 16Гб ДДР3, 4 винта в 10 аппаратном Рэйде (в материнке)).
А основная рабочая база болтается на терминале в файле.
Пришел с пылесосом и SATA-шлейфами, 60 минут и показатели rw возросли в 3-6 раз. Правда все равно не дотягивает до соточки, чую проблема уже в ОС и старом железе (возможно там и не SATA II O_O).
В итоге перенес базу на сервер 1С.
Сейчас жду еще восьмигиговую планочку, на всякий случай.
Если винт медленный а компьютер быстрый, то сжатие может давать очень серьезный прирост в производительности. При записи несжатых данных понятно, т.к. многие программы сами жмут записываемую информацию. Например 1С7.7 дбф версии при сжатии теряет от размера базы более 80%, т.е. сжимается более чем в 5 раз, понятно что это будет быстрее работать на сжатом винте, если сервер мощный.
Блин, да что ж такое, ну почему экономия всегда на самом необходимом...
Иногда хочется руки оторвать за такие "недосервера"... Такое ощущение, что есть какая-то "гнилая методичка", в которой сказано, что сервер ни что иное, как просто более мощная офисная машинка... Мало того что железо по части дисковой подсистемы полное говно, так ещё и умудрились сделать два косяка по части надежности хранения данных: сделали программный рэйд и воткнули сжатие.
На будущее для серверов:
1. Не экономить на дисковой подсистеме (контроллер и винты)
2. Использование внешнего Raid контроллера (желательно с батарейкой)
3. Использование Raid 6 или Raid 10
4. Использование жестких дисков для серверов или хотя бы повышенной надежности
5. НЕ ИСПОЛЬЗОВАТЬ ДЕФРАГМЕНТАЦИЮ !!! Иначе рискуете в один момент остаться без данных
6. НЕ ИСПОЛЬЗОВАТЬ СЖАТИЕ ТОМОВ!!! иначе тоже что и в п.5
7. Памяти на сервер ставить максимально возможный объём - желательно чтобы база полностью помещалась в оперативке
8. Хороший ИБП, чтобы в случае чего была возможность полностью выгрузиться базе из оперативки...
Ну это ток часть...
Соответственно Вам кучу терпения, убрать сжатие на винтах, постараться пнуть руководство чтоб оно раскошелилось и хотя бы дало денег на смену дисковой подсистемы... Просто в данном случае любой мало-мальский косяк по питанию или по дискам - и конец всей базе "эски"
Иногда хочется руки оторвать за такие "недосервера"... Такое ощущение, что есть какая-то "гнилая методичка", в которой сказано, что сервер ни что иное, как просто более мощная офисная машинка... Мало того что железо по части дисковой подсистемы полное говно, так ещё и умудрились сделать два косяка по части надежности хранения данных: сделали программный рэйд и воткнули сжатие.
На будущее для серверов:
1. Не экономить на дисковой подсистеме (контроллер и винты)
2. Использование внешнего Raid контроллера (желательно с батарейкой)
3. Использование Raid 6 или Raid 10
4. Использование жестких дисков для серверов или хотя бы повышенной надежности
5. НЕ ИСПОЛЬЗОВАТЬ ДЕФРАГМЕНТАЦИЮ !!! Иначе рискуете в один момент остаться без данных
6. НЕ ИСПОЛЬЗОВАТЬ СЖАТИЕ ТОМОВ!!! иначе тоже что и в п.5
7. Памяти на сервер ставить максимально возможный объём - желательно чтобы база полностью помещалась в оперативке
8. Хороший ИБП, чтобы в случае чего была возможность полностью выгрузиться базе из оперативки...
Ну это ток часть...
Соответственно Вам кучу терпения, убрать сжатие на винтах, постараться пнуть руководство чтоб оно раскошелилось и хотя бы дало денег на смену дисковой подсистемы... Просто в данном случае любой мало-мальский косяк по питанию или по дискам - и конец всей базе "эски"
(30) akaRev, Изначально вопрос по теме звучал так:
"Как влияет сжатие тома на работу файловых БД".
Где Вы видели такие офисные машинки?, по меркам 2005-2007 года сервер, описанный в первом посте, был достаточно мощным и отвечал тогдашним требованиям.
Ха, это Вы конечно загнули, из этого выходит, что для сервера на основе SuperMicro SYS-7037A-I я должен воткнуть не 32Гб, а 1Тб оперативки. (итоговая стоимость сервера с ПО составит всего то 2 миллиона)
Во-первых, я уже написал, что снял сжатие, а также в сообщении написал что файловая база была перенесена на сервер 1С.
Смена дисковой подсистемы не имеет смысла, так как все остальное в сервере (в данном случае идет речь об изначальной роли сервера, а именно сервер терминалов) не будет справляться с необходимой нагрузкой. Здесь только замена сервера.
ИБП есть, хватает минут на 10.
А вот это, аргументируйте.
"Как влияет сжатие тома на работу файловых БД".
Где Вы видели такие офисные машинки?, по меркам 2005-2007 года сервер, описанный в первом посте, был достаточно мощным и отвечал тогдашним требованиям.
Памяти на сервер ставить максимально возможный объём
Ха, это Вы конечно загнули, из этого выходит, что для сервера на основе SuperMicro SYS-7037A-I я должен воткнуть не 32Гб, а 1Тб оперативки. (итоговая стоимость сервера с ПО составит всего то 2 миллиона)
убрать сжатие на винтах,
Во-первых, я уже написал, что снял сжатие, а также в сообщении написал что файловая база была перенесена на сервер 1С.
постараться пнуть руководство чтоб оно раскошелилось и хотя бы дало денег на смену дисковой подсистемы...
Смена дисковой подсистемы не имеет смысла, так как все остальное в сервере (в данном случае идет речь об изначальной роли сервера, а именно сервер терминалов) не будет справляться с необходимой нагрузкой. Здесь только замена сервера.
Хороший ИБП, чтобы в случае чего была возможность полностью выгрузиться базе из оперативки...
ИБП есть, хватает минут на 10.
6. НЕ ИСПОЛЬЗОВАТЬ СЖАТИЕ ТОМОВ!!! иначе тоже что и в п.5
А вот это, аргументируйте.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот