Вопрос: даст ли замена винтов HDD на SSD (при прочих равных) прирост производительности на чтение/запись для 1C 7.7 + SQL 2000?

ПРирост даст переписывание конфигурации на прямые запроса. Вот тут точно.

(1) ещё не хватало. Интересует, на вскидку, какой прирост может дать апгрейд дисковой системы.

процентов 5

(2) Даст, но небольшой. Переписывание запросов - раз в пять быстрее будет (зависит от отчета).

(3) поддержу

+4 Для сравнения. Не так давно оптимизировал отчет. Исходное время выполнения - 35 минут. Время выполнения после оптимизации - 6 минут. Чисто программная оптимизация.

(0) Даст. Но не ту, которая ожидается:)

К примеру, вот здесь:
http://www.ixbt.com/portopc/hdd-ssd-2.shtml
на простом сравнении показано что скорость чтения/записи данных отличатся в среднем в 2 раза в пользу SSD.

Почему такую оценку производительности нельзя применять в моем случае?

Размер базы 12 гигов. SQL использует в пределах 2-х гигов. Значит далеко не вся база сидит в памяти. И полагаю идет постоянное обращение к дисковой системе.

здесь все разжевано По одному SSD под каждую БД или обе БД на одном SSD - есть-ли разница?

(8) потому, что чтение/запись на диск занимает не 100% работы

(0) ставь два ssd:
1-й для *.mdf
2-й для *.ldf

(9) вы не полагайте, а счетчики посмотрите

я тож считаю, что SSD для SQL в вашем случае почти не поможет, вот если бы DBF..

(12) а для свопа?

(10) разжевано для dbf. У меня другой случай.

(13) обоснуйте

(14) таки да

(16) так вы хоть какую-то вводную дайте, кроме "7.7 + SQL":
Текущая система хранения, статистика ее использования (средние, пиковые, фоновые скорости чтения/записи, IOPS, продолжительность пиков, критичность скорости работы при пиковой загрузке)

(15) да не совсем другой случай.Есть же еще и блокировки sql.
Очень грубый пример ( зато понятный)
В модуль проведения ставим
Предупреждение("Ждем !!!");
Начинаем проводить документ
Все далее пока не пройдешь этот оператор
скорость дисков вообще не имеет никакого значения.

(19) Объясню, почему ты не прав. В описанном тобой случае - да. Т.к. в твоем модуле не будет обращения к БД. В реальности же - в модуле вместо "Предупреждение" имеем "Рассчитать" и "РасходДвижениеВыполнить". А это уже обращение к БД. И тут уже важна скорость чтения и записи.

(20) я прав
пример показывает что в этом случае база ожидает окончания блокировки.( рассчитать отличается только тем что время ее выполнения меньше чем у Предупреждение).
как бы пример показывает что не все решается диском и не более того.

(0) В сравнении с SAS будет до 10% прироста. Но если есть тяжелые запросы (неважно в модуле документа или отчете) то толку с такой замены нету.
Вам правильно сказали - прямые запросы и правильно созданный рейд на SAS дисках решают много вопросов. При этом особой разницы между 2000 и 2008 скулем нету. Разница только в удобстве администрирования.

(0)Зависит в первую очередь от того какой диск стоит сейчас и как он справляется.

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

Если текущий диск более-менее справляется то общий прирост производительности будет небольшим.

(22)Думаю что нельзя однозначно говорить о каком то приросте в процентах. Сильно зависит от многих факторов, и при различных сценариях работы прирост скорости будет разным.

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

(24) "Полезность SSD будет прямо пропорциональна интенсивности работы с базой, и обратно пропорциональна количеству установленной памяти."
В типовых дофига алгоритмов, которым пофиг на диск и память и которые тупо насилуют процессор..

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

(0) Прямые запросы еще не предлагали?

Практика подсказывает, что под SQL ставишь сервер с кучей памяти, раза два более быстрыми дисками - быстродействие типовых 1С вырастает процентов на 10-20. Количество "ошибок транзакций", то есть моментов, когда ты ждёшь, когда кто-нибудь другой закончит проводить документ, модет снизиться кардинально. А вот с общим субъективным быстродействием гораздо хуже.

вставлю свои 5 копеек, была практическая задача в одной контре, один программист написал запрос - ввиду объемности данных и кривизны рук отчет формировался около часа, директор принял кординальное решение увеличить производительность компа заменой винтов (стоял RAID 5 из 3 винтов SAS Seagate 10000rpm) на рейд 5Е из 5 винтов SSD, в результате удалось выиграть пол часа, отчет стал формироваться 20-25 минут. Мною был переписан отчет на проямой запрос с использованием библиотеки 1С++ - результат время выполнения отчета максимум 1,5 минуты.

(29) подсадить на 1с++ это шикарное решение!

(30) всегда есть альтернатива ToySQL к примеру

(30) Думаешь надо было раскрутить на такое?
http://parallel.ksu.ru/cluster/images/skif_msu/9.jpg

Жаль у меня фотки нет, кстати там стоят SSD Seagate ST480FP0021 они кажется по 600 долларов за штуку обошлись, так что переписать запрос на проямой было не таким уж плохим решением :-)

(33) вот ты пишешь 1с++ замечательно, SSD гуано. но ведь 100% местная клюшка с какой либо нетленкой и прикрученной сбоку 1с++ криво шатается и это же не есть великое достижение, чтоб радоваться?

(34) если честсно то я ничего не понял...
Для себя, считаю достижением решать проблеммы с производительностью не апаратной частью (читай деньгами), а программно (читай умом)

(34) Да, несомненно, стоит радоваться каждому прямому типовому высеру 1С. Что ни релиз - сплошная радость и редкостно меткое попадание в струю ей же самой придуманной методологии...

(31) А посадить на 1С это идея не хуже?
Ну к примеру поставил ты 7-ку, через 3 года вышла 8-ка и всё ищи специалистов
Поставил 8-ку - поменяли методологию с обычных форм на УФ - и опять ищи специалистов
Поставил УФ - опа биби - это такси приехала ... ну ты понял

через 3 года бабай такси здравствуй метро - фирма ищет специалистов

(29)И?
В чем суть?
Любое решение можно переписать чтобы быстрее работало нежели стандартное. Можно и скуль пропатчить, для своих задач.
Вопрос лишь в том кто это будет делать, за какое время, и сколько денег попросит.
Ну а потом кто это будет поддерживать, и где брать денег на поддержку.

(37) 1c это идея даже лучше, чем ты можешь себе представить. на рынке полно как специалистов по 1с, так и дятлов...

(37) Тут слабое звено - сам заказчик :)

(38) Если бы он придумал свою подсистему доступа к данным/класс с закрытым кодом - было бы действительно трудновато разобраться.
Если постоянно что-то дорабатываешь нужно иметь на это деньги. Вроде логично. Если хочешь сделать лучше чем у 1С/соседа/конкурента - надо приготовить больше денег. Вроде тоже логично.

(4) Ошибаешься, переписывание запросов дает прирост скорости около 4000%. Правда вывод данных в печатную форму остается медленным (((

господа, мы отошли от темы нашего обсуждения: "SSD на сервер для 1с 7.7 + SQL 2000 стоит ли?" однозначный ответ да стоит если деньги позволяют, да это ускорит выполнение зависящих от дисковой подсистемы задач, главное что должен понимать человек который будет это внедрять, так это то что замена винтов на SSD не сделает из его компьютера/сервера самолет, а только на какое-то количество % ускорит его.

У самого на домашнем компьютере крутится SSD, для работы с 1С все данные стараюсь держать на нем. Быстрее понятие растяжимое, даже выиграш в пол минуты уже доставляет удосовльствие.

(41) Имелось в виду выполнение всего отчета, а не время выполнения запроса.