Добрая пятница, форумчане.

Я не админ, а нормальных админов нет рядом(

Есть сервер 1с на винде и с МСскулем, несколько десятков баз.
На С - винда и програм файлз, на D - все базы, и их файлы логов транзакций .ldf, на E - srvinfo\reg_1541 с журналами 1с и кешами.

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

Ну а посоветоваться особо не  с кем, посоветуйте пожалуйста вы, дорогие - где у вас лежат .ldf и имеет ли это какой-то смысл

диски SSD?

(1)да

положите лучше на отдельный/или raid SSD tempdb

Я бы ещё сам скуль и сервер 1С разнес на разные сервера.

(0) На более-менее новом компе - без разницы (при модели восстановления БД = Простая, тем более)
Если на сервере развёрнут RAID - вообще без смысла (система на отдельном диске, всё остальное в RAID)

Имеет смысл TempDB положить на виртуальный RAM-диск (решение времён для машин с 16 Гб памяти и Win2003)

Раньше (когда деревья были большими, а диски маленькими и медленными), была такая рекомендация:
Систему, файл БД и Файл лога размещать на разных ФИЗИЧЕСКИХ дисках (т.е. разделы одного не подходят)

(0) Говорит он правильно. Но жить можно и так. Если бы было три жестких диска, то на третий имело бы смысл писать логи. И это бы действительно ускорило работу.
А т.к. у Вас их два, возникает еще вопрос отказоустойчивости и восстановления. Места на диске. Места, где хранятся бекапы. Достаточно ли его. И прочее.

А так оно ускорит, но не прямо существенно. Если прямо зуд в руках, то можно виртуальный диск сделать и в него логи транзакций писать. Но если Вы нищеброды без рейда, непонятно зачем. Сбой (а рано или поздно он случится) дороже встанет.

1С в основном читающая система, а не пишущая. Вот если бы билинг какой, там да, нужно разносить.

(2) Если ssd, то я бы не разносил. ssd на который часто идет запись быстрее грохнется. Так что когда это произойдет (и при условии что бекапы на другом диске) проще будет восстановиться. Системный останется, бекапы останутся. Проще будет работу восстановить в разумный срок.

диски в рейде. Не уверен насчет C. D где базы и логи транзакций - там физически 2 диска с зеркалированием. E где кеши и журналы 1с - тоже.

Типа имеет смысл купить еще диск в рейде типа G и класть на него чисто логи транзакций? Или это ни о чем инсинуации?

Сейчас на диске D где базы и логи транзакций - очередь к диску 0.01

Где E - srvinfo\reg_1541  f - очередь к диску 0,01, иногда скачет до 0,5

(9) Классика по настройке sql подразумевает разделение на физический диск с базой и физический диск с транзакциями. Но дьявол он в деталях.
Возможно ли впихнуть невпихуемое и прочее. Само решение зеркалировать показывает что что-то там странное творится у Вас.

(10) Может я не правильно называю. В D например 4 ТБ, но состоит он физически из двух SSD по 4 ТБ, и типа если они сдохнет то информация не должна пострадать. То же самое с E

(0) идеально еще каждую базу на отдельные два диска

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

но такое нереально
так можно дойти и разные таблички в одной базе на разных дисках
и даже одну большую табличку по разным дискам раскладывать

(13)
Уже https://v8.1c.ru/platforma/kopii-baz-dannykh/

(11) Зеркальные диски пишутся одновременно, т.е. если дохнет один из SSD, то, с вероятностью 99,9, сразу помрёт и второй.
Тут уже лучше HDD - они медленнее, но дохнут в разное время

(0) несколько десятков баз и нет сисадмина? наверное, там у вас клуб самоубийц

(2) Какая скорость чтения и записи?

(15) Лучше для чего? Отказоустойчивости это не прибавит, а вот скорости убавить. И HDD точно так же парами мрут. Но это нужно быть очень удачливым, что бы на такой дубль попасть.
Просто почаще бэкапы делай и проверяй.

(0)
1) Разговор можно начинать только если речь о разных физических дисках/массивах, а не буковках одного физического.
2) Гораздо важнее вынести отдельно всю tempdb, чем ldf от основной базы.
3) Вот когда п.2 выполнен, тогда можно думать про вынесение ldf отдельно, и то - это актуально только для очень нагруженных на запись баз, вряд ли ваш случай.

(18) Лучше для спокойствия.
Медленнее, но и подохнут в разное время (если не словить комбо - но, для сего, надо очень сильно накосячить для Вселенной)

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

(21) современные ОС уже давно кэшируют дисковые операции в оперативку
так что эта tempdb скорее всего будет в ram, если ее много
без всяких рамдисков

(7) запусти какой нибудь отчет или проведение, и понаблюдай за темп папкой юзера под которым сервер 1с крутится. Он там строчит врем файлы только в путь.

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

Банальный пример - ускорит ли работу создание виртуального диска в рам и запись логов в него? Ну безусловно. Но есть ли у Вас место для рам. Способны ли Вы его увеличить. Размер и целесообразность. А главное насколько надежна конструкция, например питание и прочие ups. Если нет, то будет серия сбоев по питанию и Вам звиздец.
Остальное из той же серии. Диск ставить дополнительно/перестраивать рейд и т.д. А место есть в слоте или контроллер тоже надо менять?
Рейд якобы из 2 дисков. А почему не из трех (пяти как у белых людей)? Что вообще за решение зеркалировать ssd другим ssd? Ну если это правда. Что сомнительно.

Далее если у Вас нет своего системного администратора, который занят только этим и соответственно шарит, значит компьютеров у Вас мало и денег тоже. Ну и зачем тогда решения затрагивающие бюджет? Они не будут приняты. Ну пока что-то большое хорошо так не рухнет.

Так что тут лучше (если я верно понял ситуацию) ничего не делать. Сильно лучше не будет. В теории-то будет. А на практике нет.

(0) Но в целом конечно, в идеале все по устройствам раскидать. Базу, транзакции, да и системный диск (темпы 1С туда пишутся обычно). Просто в конкретном случае - не факт что именно это узкое место.

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

(26) Причем не только tempdb, но и каталог временных файлов, используемый сервером 1с. Да и весь кластер нужно на быстром диске держать.

(27) Да, про кластер хотел написать, но забыл))) Было удивительно как база стала работать в два раза быстрее, после переноса кластера в RAM диск.

(28) А как часто РАМ диск синхронизируется на случай неожиданного ребута?

(0) Прирост будет, но небольшой и то если это разные физические диски, а не виртуалки. Сейчас цена на диски позволяет разнести все по отдельным дискам - систему, темпы, mdf, ldf. И порой даже 15% улучшение радует на тяжелых базах.
Как определить будет ли по простому - запустите монитор ресурсов в активную фазу работы и посмотрите, какие диски нагружены, есть ли очередь отсюда думайте. Чаще базы разнести по разным дискам лучше, чем файлы журналов.

+(28) Каким софтом?

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

(20) HDD в зеркале дохнут парами (даже тройками и тд) ничуть не меньше чем SSD, при ребилде и общей панике, особенно если диски одной партии как обычно.

(32) <чтобы база под одним серваком, а 1с общался с ней только по сети. >

только сеть то какая должна быть, 10гигабитная?

(34) если запросами в циклах не спамить то 1 гигабит потянет,  2.5 гигабит уже лучше а 10 гигабит идеально

(34) в зависимости опять же от нагрузки. а она в задаче не указана.

Странные люди.
Первое: Пришел чувак и говорит делайте так. Вы вопрос задать не пробовали: "Что бы, что? Какую проблему ты сейчас решаешь?". Вот вам новая установка: Носите на голове трусы. Давайте идите на форумы начинайте выяснять почему этого не надо делать.
У вас есть проблема с производительностью? Вы упираетесь в запись на диск? Если нет, то чего надо то? Если да, надо начать разбираться по какой причине не хватает производительности дисков и по дороге уже можно в том числе, вынести логи на отдельный диск(ну а чобы нет). Если нет, то конец алгоритма.

Второе: Вам надо мастер классы писать, как написать длинное сообщение и не сообщить в нем ничего: Есть ли проблемы с диском(мы же про диск сейчас?), совершенно непонятная конфигурация. Почему каталог сервера1С на отдельном диске. Какие диски быстрые, какие медленные.

Третье: Имеет значение какая модель восстановления используется для ваших баз(это вы указать тоже забыли). Eсли модель восстановления полная и нагрузка серьезная, Тогда постоянная параллельная нагрузка на запись(запись логов\удаление логов) на один диск с БД, совершенно не к чему. Очень удобно хранить и ротировать логи на отдельном диске при полной модели. При простой модели она занимается их обслуживанием в свободное время от свободного времени. И нагрузка тоже в наличии, но не помню кейсов, что-бы это было узким местом для простых моделей.

(4)С какой целью?