Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | | | | | | |
Гм. он точно так же снится как и на одном диске и не важно... 21.10.08 17:08 Число просмотров: 2998
Автор: TRESPASSER[CfK] Статус: Незарегистрированный пользователь
|
Гм. он точно так же снится как и на одном диске и не важно чей он - ОСи или чего то другого. Это актуально только в контексте того что фактор риска умножается на 2 в случае со страйпом, а отказоустойчивость - тут неподходящее выражение, т.к. данные имеют смысл только в рантайме (точно так же = какая отказоустойчивость у 1 диска).
Вообще это конечно может привести к труднопредсказуемым последствиям. Как минимум из худших вариантов это БСОД.
И потом насколько я понял - разговор изначально шел именно о быстродействии.
|
|
<operating systems>
|
[NT] Поспорил тут с 1Сниками. 02.05.08 17:14 [Den]
Автор: Lurga Статус: Elderman
|
Есть, значит, Цитрикс-сервер на Вынь2К3, к одной из сетевух которого по гигабитке цепляется второй сервак с SQL. Никаких других функций на него не возлагается, просто обрабатывает SQL-запросы от первого сервера. Во втором серваке есть два винта -- самсунговская 120-ка и сигейтовская восьмидесятка.
Собственно, возник вопрос, куда рассовать свлопники Винды и SQL для повышения быстродействия? Я склоняюсь к тому, чтобы на системном винте (80гигов) жёстко выделить Винде гигов пять под свой своп, а остальное отдать под свопник SQL. 1Сники кричат, что нужно восьмидесятку разрубить пополам, на системном разделе дать место под своп Винды, а на втором -- под своп SQL.
Подскажите что-нибудь. :)
|
|
на самом деле для полноты картины не хватает данных 22.10.08 17:18
Автор: Mopok Статус: Незарегистрированный пользователь
|
на самом деле для полноты картины не хватает данных
1) какой объем базы 1С?
2) сколько памяти на серверах?
3) какая версия SQL-сервера? и какая версия винды на которой установлен этот SQL?
идеальный вариант - когда памяти достаточно для того чтобы свопы вобще отключить
кстати, заставить использовать SQL сервер более 4-х гигабайт памяти сам по себе вопрос не такой тривиальный
|
|
А виндовый своп сильно используется? 05.05.08 10:40
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 05.05.08 10:41 Количество правок: 1
|
А виндовый своп сильно используется?
(Обратить внимание на объем и среднюю скорость прокачки при высокой деловой активности).
Если сильно - видать памяти мало. Может оперативки добавить и забыть про виндовый своп. В крайнем случае завести еще терминалку и определенную группу сотрудников на нее коннектить.
Если нет возможности добавить памяти и приходися мириться со свопом, то интересным решением будет поставить еще один винт. Получится один винт - своп системы, второй - своп сервера, третий - хранилище базы. Если нагрузка на своп системы велика, то поставить пару винтов под это в РАИД0 (нулевого уровня достаточно) можно программаный РАИД, можно просто (если винда позволит) завести два свопа на разных винтах - винда рюхнет и будет стараться их параллельно/равномерно загружать.
Если нужно совсем без дополнительных вложений, то самый худший выриант - разбить винт пополам, каждая половина для своей задачи. А именно, предположим, что в процессе работы большая нагрузка на оба свопа и они разведены на каждый из двух равных разделов одного диска. В результате головка этого диска будет летать из одного конца в другой и даже при маленькой прокачке получим очень маленкую пропускную способность и высокую нагрузку. Если же нагрузка на базу (хранилище) велика, то самым плохим решением будет на том же диске с базой, на другом разделе заводить еще какой-либо из свопов, на который велика нагрузка.
Рекомендация: На каждом диске по одному разделу. Самый нагруженый своп расположить на одном винте с самым не нагруженым. Если сама база является не сильно нагруженой или наоборот сильно нагруженой, то ее объединить соответственно с сильно нагруженным или не нагруженным свопом.
|
|
ИМХО, Самсунг фтопку! 04.05.08 20:52
Автор: Den <Денис Т.> Статус: The Elderman
Отредактировано 08.05.08 14:08 Количество правок: 2
|
ИМХО, Самсунг фтопку!
Или в какую-нибудь рабочую станцию.
80-ку можно оставить для pagefile.sys и tempdb.
Для системы и БД (в разных разделах) надо иметь хотябы два хороших винта в хардовом зеркале - тут тебе и прибавка в скорости и б'ольшая надежность.
Самой системе много не надо - 24Гб за глаза и за уши, все сотальное пространство - БД, резервные копии и т.п.
|
|
Разве у SQL Server есть свой своп? Или ты про tempdb? 03.05.08 15:07
Автор: :-) <:-)> Статус: Elderman
|
|
|
|
а 120-ник вообще сбоку и никак не используется? 02.05.08 21:31
Автор: dl <Dmitry Leonov>
|
|
Если речь о делении одного физического винта, то с точки зрения быстродействия тут как-то может влиять разве что фрагментация диска. Так что если что и разносить, то не фиксированный своп винды и sql, а систему и свопы. Хотя разница все равно будет копеечная, если вообще заметная.
|
| |
На 120-нике у него наверное базы лежат 03.05.08 18:32
Автор: :-) <:-)> Статус: Elderman
|
По умолчанию размер tempdb не ограничен и легко может сожрать все свободное место.
Фрагментация тоже хоть и незначительная, но будет - tempdb по умолчанию создается маленького размера и увеличивается по мере необходимости на 10%.
При размещении temdb на системном диске надо об этом помнить и соответственно настраивать ее параметры: чтобы она не расширялась слишком часто, чтобы не заполнила весь диск.
А просто разместив tempdb на отдельном разделе, можно оставить настройки по умолчанию и забыть - других аргументов "за" я не вижу.
|
| |
Пардон, вчера спьяну не въехал. 02.05.08 22:24
Автор: Fighter <Vladimir> Статус: Elderman
Отредактировано 03.05.08 10:30 Количество правок: 1
|
|
Выигрыш будет не копеечный. Своп SQL нужно выносить на отдельный от системы винт. Виндовский нужно оставить на системном.
|
| | |
на разных винтах - да 03.05.08 12:54
Автор: dl <Dmitry Leonov>
|
|
Но тут речь была о делении одного физического диска.
|
| | | |
Конечно на разных. Деление одного физического на два логических вообще выигрыша не дает. 03.05.08 16:39
Автор: Fighter <Vladimir> Статус: Elderman
|
> Но тут речь была о делении одного физического диска.
Я ж и говорю, что вчера на пьяную голову не сообразил сразу о чем речь.
|
| | | | |
Если делить 1 диск то я делаю так: 20.10.08 16:53
Автор: TRESPASSER[CfK] Статус: Незарегистрированный пользователь
|
> > Но тут речь была о делении одного физического диска.
> Я ж и говорю, что вчера на пьяную голову не сообразил сразу
> о чем речь.
Если делить 1 диск то я делаю так:
сделать 1 раздел под свап(обычно это С диск)
засунуть раздел и файл в максимально в физическое начало диска.
З.Ы. а вообще конечно лучше скинуть систему на отдельный винт. А свап сделать на каком нить винте типа раптора либо еще лучше -2 раптора в страйпе. (Это если конечно памяти уже некуда совать а делать что то надо)
|
| | | | | |
Страйп - это РАИД-0? То есть отказоустойчивость системы в... 20.10.08 18:35
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> З.Ы. а вообще конечно лучше скинуть систему на отдельный
> винт. А свап сделать на каком нить винте типа раптора либо
> еще лучше -2 раптора в страйпе. (Это если конечно памяти
> уже некуда совать а делать что то надо)
Страйп - это РАИД-0? То есть отказоустойчивость системы в процессе работы должна сильно упасть?
|
| | | | | | |
Упадет минимум в два раза, по сравнению с stand-alone диском. 20.10.08 19:24
Автор: Den <Денис Т.> Статус: The Elderman
Отредактировано 20.10.08 19:29 Количество правок: 2
|
Вообще отказоустйчивость снижается пропорционально количеству дисков в RAID 0.
А stripe, на сколько я помню, это заданного размера блок данных, записываемый на каждый диск в массиве.
|
| | | | | | |
Отказоустойчивость свопа? 20.10.08 18:50
Автор: Ustin <Ustin> Статус: Elderman
Отредактировано 20.10.08 19:00 Количество правок: 1
|
|
|
| | | | | | | |
Именно системы. Если падает диск со свопом, то системе начинает сниться @#$%ец. Особенно если это системный своп. 20.10.08 20:26
Автор: Fighter <Vladimir> Статус: Elderman
Отредактировано 20.10.08 20:29 Количество правок: 1
|
|
|
| | | | | | | | |
Причем имеется в виду всей вычислительной системы, а не операционной системы. 21.10.08 11:26
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
|
|
| | | | | | | | | |
Именно так. 21.10.08 22:03
Автор: Fighter <Vladimir> Статус: Elderman
|
|
|
| | | | | | | | | |
Гм. он точно так же снится как и на одном диске и не важно... 21.10.08 17:08
Автор: TRESPASSER[CfK] Статус: Незарегистрированный пользователь
|
Гм. он точно так же снится как и на одном диске и не важно чей он - ОСи или чего то другого. Это актуально только в контексте того что фактор риска умножается на 2 в случае со страйпом, а отказоустойчивость - тут неподходящее выражение, т.к. данные имеют смысл только в рантайме (точно так же = какая отказоустойчивость у 1 диска).
Вообще это конечно может привести к труднопредсказуемым последствиям. Как минимум из худших вариантов это БСОД.
И потом насколько я понял - разговор изначально шел именно о быстродействии.
|
| | | | | | | | | | |
Ну хорошо, пусть будет "вероятность отказа" вместо... 21.10.08 17:20
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> Гм. он точно так же снится как и на одном диске и не важно
> чей он - ОСи или чего то другого. Это актуально только в
> контексте того что фактор риска умножается на 2 в случае со
> страйпом, а отказоустойчивость - тут неподходящее
> выражение, т.к. данные имеют смысл только в рантайме (точно
> так же = какая отказоустойчивость у 1 диска).
Ну хорошо, пусть будет "вероятность отказа" вместо "отказоустойчивости". В любом случае она растет пропорционально количеству дисков в РАИД-0. Почему бы не добавить еще один для ЕСС и получить РАИД-5? Быстро и даже надежнее, чем с одним диском. Тогда бы и дисков добавить. Сделать массив дисков штук так на 10 - 15, во внешней корзине, разумеется. Контроллер за штуку баксов купить, а лучше два - вдруг сгорит, чтоб сразу заменить и минимальное время простоя. Много чего хорошо, но это все не сделано, наверняка не от того, что не знают как, а от того, что дорого.
В общем хорошо быть богатым и здоровым, чем бедным и больным.
> Вообще это конечно может привести к труднопредсказуемым
> последствиям. Как минимум из худших вариантов это БСОД.
> И потом насколько я понял - разговор изначально шел именно
> о быстродействии.
Да, но без капвложений и не в ущерб надежности. Это хоть и не оговаривалось, но однозначно подразумевалось.
|
| | | | | | | | | | | |
По опыту настройки подобных связок. 11.11.08 05:02
Автор: ВНЬ Статус: Незарегистрированный пользователь
Отредактировано 11.11.08 05:13 Количество правок: 2
|
По опыту установки такого типа связок.
Конструкция:
LAN-100Mb-Switch-1Gb-TermServer-1Gb-SQLServer
На терминалке -- 1 винт, с которого ночером делается snap-backup.
Ессно, какая-то винда с возможностями терминалки. Чаще всего -- 2003.
Оперативки МНОГО, виндовый свап в самом начале винта, маленький.
На SQLServer -- Unix-like операционка, под которой крутится либо
а) сам SQL если 1С-ка отвязана от мелкомягких
б) какой-то имитатор виндов, с поднятым MS SQL
Винтов от 2 до 5 в RAID. Там -- как пожелается.
SWAP - тоже в начало винта, но не в самое, а после рутового раздела. Под базу -- тоже отдельный раздел. Копирование -- ежедневное инкрементное за 7 дней. За более ранние периоды -- воскресные ночные полные копии с остановленным SQL на отдельно примонтированный раздел (для такого случая :-), эти по 4 штуки на месяц. Ну, и ежемесячные, на год -- 12 штук. Всё утаптывается в архив.
Иногда к SQLServer подключается либо отдельный винт, либо какой-нть netstorage, по отдельному каналу, питание которого включается только тогда, когда делается бекап, либо для восстановления.
По поводу свапов вообще -- для них, как и для TEMP желательно отдельный раздел, чтобы не морочиться с возможными сбоями при активом использовании.
Если же не RAID, то на одном винте винда с отдельным разделом в начале под свап, SQL-база на другом, который побыстрее, и на нём же свап для SQL, т.к. он, в реальных задачах, свапится намного чаще, и тоже в отдельном разделе. Свапы однозначно желательно разнести по разным винтам. Как, собственно, и ОС, на которой крутится SQL с собственно файлами базы. А лучше -- поставить третий винт под свапы, небольшой, но шустрый. Держать систему на одном разделе со свапом -- не есть гуд. Свап всегда зачистил -- и вуаля. И раздел с системой меньше юзается, меньше шансов на слёт системы.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
