Легенда:
   новое сообщение
    закрытая нитка
    новое сообщение
    в закрытой нитке
    старое сообщение
         
		 | 
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
 - Новичкам также крайне полезно ознакомиться с данным документом.
   
  |   | 
На 120-нике у него наверное базы лежат  03.05.08 18:32  Число просмотров: 3641
 Автор: :-) <:-)> Статус: Elderman
 | 
 
По умолчанию размер tempdb не ограничен и легко может сожрать все свободное место.
 Фрагментация тоже хоть и незначительная, но будет - tempdb по умолчанию создается маленького размера и увеличивается по мере необходимости на 10%.
 При размещении temdb на системном диске надо об этом помнить и соответственно настраивать ее параметры: чтобы она не расширялась слишком часто, чтобы не заполнила весь диск.
 А просто разместив tempdb на отдельном разделе, можно оставить настройки по умолчанию и забыть - других аргументов "за" я не вижу.
 | 
 
| 
<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 с собственно файлами базы. А лучше -- поставить третий винт под свапы, небольшой, но шустрый. Держать систему на одном разделе со свапом -- не есть гуд. Свап всегда зачистил -- и вуаля. И раздел с системой меньше юзается, меньше шансов на слёт системы.
 | 
 
 
  
 
 | 
 |