Главная Virtualization, Windows, Без рубрики, Новое Производительность Hyper-V: тюнинг и мониторинг.
  • Производительность Hyper-V: тюнинг и мониторинг.

    Как известно, до определенного времени в сфере виртуализации серверов «правил бал» VMware со своим ESX. Теперь же, с выпуском Hyper-V Microsoft постепенно «наступает на пятки». Насколько успешно – вопрос, конечно, весьма спорный, учитывая, что VMware ESX существует на рынке намного дольше. Тем не менее, Hyper-V привлекает все большее и большее внимание по мере появления новых фич – таких, как Cluster Shared Volumes и Live Migration в Windows Server 2008 R2, или Dynamic Memory в готовящемся к выходу Service Pack 1.

    В этой статье мы безо всякого marketing bullshit, мы поговорим о «тонкой настройке», призванной повысить производительность системы на базе Microsoft Hyper-V. Я попытаюсь рассмотреть некоторые архитектурные особенности Hyper-V, дать несколько советов о том, как можно повысить производительность, не прибегая к новым финансовым затратам, и как можно увидеть, что вообще происходит «там, внутри».

    Как повысить производительность?

    Разумеется, если что-то в системе начинает «подтормаживать» – то самым простым путем будет купить более мощную систему. Но это не всегда приемлемо, и не только по финансовым причинам. К примеру, замена оборудования часто сопровождается простоем системы, что не всегда допустимо. В этой части статьи мы посмотрим, как можно попытаться повысить производительность системы на базе Hyper-V без вмешательства в аппаратную часть.

    Виртуальные процессоры

    В документации Microsoft довольно часто встречается понятие «логический процессор». Под этим термином понимают процессорные ядра. Виртуальные процессоры – это те процессоры, которые видит гостевая ОС на виртуальной машине. Допустим, у нас имеется хост с двумя процессорами Intel QuadCore Xeon, на котором запущено 10 виртуальных машин, в настройках каждой из которых установлено по два виртуальных процессора. В итоге у нас получается 8 логических процессоров и 20 виртуальных процессоров.

    Сколько же процессоров назначать виртуальным машинам? Hyper-V позволяет назначить каждой виртуальной машине максимум 4 процессора. Кроме того, разные ОС могут поддерживать разное максимальное количество процессоров. В среде Hyper-V официально поддерживается Windows Server 2003, Windows Vista и Windows XP SP3 с двумя виртуальными процессорами, Windows Server 2008 R2, Windows 7, RHEL и SLES (с Linux Integration Services 2.1) – до четырех виртуальных процессоров.

    Использование нескольких виртуальных процессоров может приводить к некоторому снижению производительности, но это более актуально для Windows Server 2003. При этом Windows Server 2008 R2 будет нормально работать даже с четырьмя виртуальными процессорами.

    Так сколько же виртуальных машин можно запустить на одном физическом сервере? Microsoft официально поддерживает до 8 виртуальных процессоров на 1 логический процессор. При этом для наибольшей производительности рекомендуется делать не более 4 виртуальных процессоров на 1 логический.

    Как же посчитать такое соотношение? Разумеется, можно «руками» пройтись по настройкам всех виртуальных машин, и посчитать виртуальные процессоры. Но что делать, если виртуальных машин много, или мы имеем дело с кластером, где виртуальные машины периодически мигрируют с одного узла на другой? Здесь поможет скрипт из одной строки на PowerShell, который я любезно позаимствую у Бена Армстронга:

    write-host (@(gwmi -ns root\virtualization MSVM_Processor).count / (@(gwmi Win32_Processor) | measure -p NumberOfLogicalProcessors -sum).Sum) ”virtual processor(s) per logical processor” -f yellow

    clip_image002

    Если вы выбираете железо – то, помимо гигагерцев и количества ядер, нужно смотреть на объем кэша L2/L3. Чем он больше – тем выше будет производительность, особенно для виртуальных машин с большими объемами памяти. Кроме того, очень желательно выбирать процессоры с поддержкой технологии преобразования адресов SLAT. В чем смысл этой технологии? Дело в том, что гостевые ОС не работают с физической памятью напрямую. Вместо этого им выделяется пространство гостевых физических адресов. При обращении к памяти гостевой ОС стек виртуализации преобразует с помощью специальной таблицы этот адрес в физический адрес страницы памяти. Это создает дополнительную нагрузку на память и на процессор. Технология SLAT позволяет осуществлять такое преобразование адресов непосредственно процессором, в результате чего накладные расходы сильно сокращаются. В некоторых случаях использование SLAT позволяет получить прирост производительности до 40%. Чтобы узнать, поддерживает ли процессор технологию SLAT – нужно глянуть в спецификацию. У AMD это может называться Rapid Virtualization Indexing (RVI) или (ранее) Nested Page Tables (NPT), у Intel – Extended Page Tables (EPT).

    Память

    Память – это едва ли не наиболее критичный для производительности ресурс. До недавнего времени выделение памяти для виртуальных машин вызывало некоторые затруднения. Дело в том, что память виртуальной машине выделяется «жестко», и изменить это значение можно только остановив гостевую ОС, что не всегда приемлемо. Рассчитать же точно, «сколько вешать в граммах» – зачастую не такая и простая задача, так как потребление памяти может зависеть от множества факторов. Поэтому, как правило, брали требования вендоров ПО а-ля «на 100 пользователей – 2 Гб памяти» и прибавляли (а иногда и не прибавляли) некоторый запас. Все бы ничего, но тут кроются две проблемы. Во-первых, можно ошибиться в расчетах (а вендорские требования – это «сферический конь в вакууме», они вполне могут не иметь ничего общего с реальностью) – что приведет к падению производительности. Во-вторых, если выделить виртуальной машине слишком много памяти – она будет простаивать, что по сути означает выброшенные на ветер деньги. Особенно, если виртуальных машин больше одной. С выходом Service Pack 1 для Windows Server 2008 R2 появилась новая технология – Dynamic Memory, позволяющая в режиме реального времени выделять виртуальным машинам столько памяти, сколько им нужно для работы. Dynamic Memory можно сравнить с динамическими VHD, которые увеличивают объем по мере необходимости. Но, в отличие от VHD, объем выделяемой памяти может не только увеличиваться, но и уменьшаться, позволяя отдать неиспользуемую память другим виртуальным машинам. Хотя на момент написания статьи Service Pack 1 находится в версии Release Candidate, и потому я не могу рекомендовать использовать его в продуктивных системах – я буду касаться Dynamic Memory в дальнейшем.

    За распределение памяти отвечают пять параметров, из которых первые два могут быть изменены только при остановленной виртуальной машине, а другие два могут изменяться прямо «на лету»:

    · Startup RAM

    · Maximum RAM

    · Memory Buffer

    · Memory Weight

    Startup RAM – это объем памяти, выделяемый виртуальной машине при запуске ОС. Microsoft рекомендует значения Startup RAM 512 Мб для Windows Server 2008, 2008 R2, Windows 7 и Vista. Для Windows Server 2003 и Windows XP рекомендуется начальное значение 128 Мб. В некоторых случаях, Startup RAM можно повысить. В частности, если используются «тяжелые» серверные приложения, стартующие вместе с гостевой ОС, и потребляющие много памяти. В частности – Exchange Server.

    Maximum RAM – максимальный объем памяти, который может быть выделен виртуальной машине. Несмотря на то, что это значение может превышать объем физической памяти сервера – не обольщайтесь, это не memory overcommit, и использовать памяти больше, чем физически имеется – не получится. По умолчанию это значение равно 64 Гб, и его можно и нужно уменьшить, если необходимо ограничить «аппетит» виртуальной машины.

    Memory Buffer – один из самых интересных параметров. Он позволяет выделять виртуальной машине не ровно столько памяти, сколько ей требуется, а чуть больше. То есть, если ОС и запущенные приложения потребляют 600 Мб памяти и Memory Buffer равен 20%, то виртуальной машине будет выделено 600*(1+0,2) = 720 Мб. Если нагрузка носит пиковый характер, к примеру – это сервер БД, на котором периодически выполняют сложные аналитические отчеты – то значение Memory Buffer можно увеличить. Тогда в период очередного «пика» у виртуальной машины будет достаточный объем свободной памяти, и не понадобится обращаться к файлам подкачки. Кроме того, Memory Buffer можно увеличивать, к примеру, для файловых серверов или для веб-серверов – которым нужна свободная память для файлового кэша. Тем не менее, злоупотреблять этим параметром не стоит – поскольку если одна виртуальная машина заберет себе лишнюю память – это может означать, что кому-то она не достанется, когда будет нужна.

    Memory Weight – приоритет виртуальной машины при распределении памяти. В бета-версии этот параметр так и назывался «Memory Priority». До тех пор, пока на хосте имеется свободная память – этот параметр никак себя не проявляет. Но как только память заканчивается, и нужно у кого-то память отбирать, а кому-то – наоборот, добавить – тут-то и начинает работать механизм приоритетов. У тех виртуальных машин, у которых приоритет самый низкий – память будет отбираться в первую очередь. И, соответственно, на добавление памяти первыми в очереди встают виртуальные машины с наиболее высокими приоритетами. Для наиболее критичных виртуальных машин можно повысить приоритеты – и тогда при нехватке памяти у них будет самый большой шанс эту память получить. А для наименее критичных приоритет можно, наоборот, понизить – чтобы в случае чего у них можно было забрать излишек неиспользуемой памяти.

    Есть еще один достаточно важный параметр – Memory Reserve. Он позволяет зарезервировать определенный объем памяти для использования хостовой ОС. Этот резерв не будет участвовать в распределении между виртуальными машинами. Изменить параметр Memory Reserve можно только через реестр (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\MemoryReserve, тип параметра REG_DWORD). Резервируемый объем задается в мегабайтах. Максимальное значение – 4096. Если указать большее значение – все равно будет выделено только 4 Гб. Microsoft считает, что если следовать Best Practices, и не запускать в хостовой ОС ничего кроме, собственно, Hyper-V – то хватит и 32 Мб, но я бы все же порекомендовал ставить 1 Гб. На всякий случай.

    Дисковая подсистема

    Дисковая подсистема – наиболее типичное «узкое место», и в системе виртуализации – особенно. Дело в том, что многие приложения оптимизируют работу с диском так, чтобы операции записи-чтения были по возможности последовательными. В качестве примера можно привести базы MS Exchange Server 2010. Тем не менее, при работе множества виртуальных машин поток ввода-вывода получается случайным, и эффективность всех этих оптимизаций сводится к нулю. Решить эту проблему, помимо экстенсивного наращивания мощностей подсистемы хранения данных (добавление жестких дисков в RAID-массив, установка более высокопроизводительных контроллеров, и т.п.) можно за счет использования прямого подключения дисков к виртуальным машинам вместо VHD-файлов. К примеру, для ОС можно использовать VHD, а базы данных хранить на pass-through-дисках. Несмотря на то, что Microsoft утверждает, что в Windows Server 2008 R2 производительность VHD практически идентична прямому подключению дисков – я не готов утверждать, что это полностью соответствует действительности.

    Помимо этого, есть еще одна рекомендация относительно дисков. Не рекомендуется использовать в производственной среде VHD динамического объема, а так же моментальные снимки виртуальных машин (snapshots). Хотя по производительности динамические VHD не очень сильно уступают VHD фиксированного объема – возможно падение производительности при увеличении объема VHD-файла за счет фрагментации. Кроме этого, возможна ситуация, когда объем VHD не сможет увеличиться из-за недостатка дискового пространства – что тоже достаточно неприятно. Моментальные снимки не рекомендуется использовать по той же самой причине: они приводят к дроблению VHD на несколько файлов, что так же не лучшим образом может сказаться на производительности. И здесь есть опять же неприятный момент: если после удаления моментального снимка гостевая ОС будет перезагружаться – запустится операция слияния, до окончания которой гостевая ОС не запустится. Этот процесс может занять достаточно много времени. А если в процессе слияния закончится дисковое пространство – пиши «пропало». Виртуальную машину придется восстанавливать с резервной копии.

    Сетевые интерфейсы

    Почему-то традиционно при тюнинге производительности в первую очередь обращают внимание на процессор и память, а про сетевые интерфейсы как-то забывают. А тем не менее, сетевая подсистема вполне может стать «бутылочным горлышком». К примеру, если на виртуальных машинах запущены сервисы, генерирующие большие объемы сетевого трафика – базы данных, или файловые сервера. Помимо использования более высокопроизводительных сетевых адаптеров (1Gbps – минимум, а лучше – 10Gbps), можно с помощью виртуальных сетей разнести разные виртуальные машины по отдельным сетевым интерфейсам. Особенно, если используется iSCSI – то для iSCSI настоятельно рекомендуется использовать отдельный сетевой адаптер, а лучше – несколько. Если у вас отказоустойчивый кластер и используется Live Migration – то желательно выделить на каждом узле кластера отдельный сетевой адаптер для трафика миграции. Ну и разумеется, дешевые сетевые адаптеры SOHO-класса лучше не использовать, поскольку серверные сетевые адаптеры поддерживают такие полезные функции, как TCP Chimney Offload и Virtual Machine Queues (VMQ), позволяющие передать большую часть функций по обработке пакетов процессору сетевого адаптера.

    Хостовые и гостевые ОС

    Так же нужно обратить внимание на настройки ОС – как хостовой, так и гостевых. Я намеренно не буду говорить о тюнинге отдельных приложений – эта тема достойна даже не отдельной статьи, а целой книги. Причем некоторые приложения, такие, как SQL Server или Exchange Server – даже отдельных книг.

    Что касается хоста. Во-первых – не рекомендуется запускать в хостовой ОС какие-либо роли и приложения. Microsoft рекомендует запускать в хостовой ОС только агенты систем управления и резервного копирования. Кроме этого, рекомендуется устанавливать ОС в режиме Server Core: это снизит потребление памяти, а так же объем обновлений, и повысит безопасность.

    В гостевых ОС – во-первых, рекомендуется использовать как можно более новые версии ОС. В частности, Windows Server 2008 R2 работает в виртуальной среде намного лучше, чем Windows Server 2003. Так же необходимо следить, чтобы в гостевой ОС была установлена последняя версия служб интеграции – это тоже может влиять на производительность.

    Мониторинг производительности Hyper-V

    Как узнать, что производительность падает, до того, как пользователи начнут жаловаться, что у них «все тормозит»? Наилучший способ – использование счетчиков производительности. Не стоит использовать инструменты мониторинга внутри гостевой ОС – из-за особенностей архитектуры Hyper-V они не всегда могут показывать достоверную информацию. Использовать лучше всего счетчики в хостовой ОС, причем лучше всего – те, что непосредственно связаны с Hyper-V.

    Hyper-V Monitoring Hyper-V - Performance Monitor CPU

    CPU

    Счетчик Hyper-V Hypervisor Logical Processor\% Total Run Time покажет загрузку общую нагрузку на процессоры хоста. Для того, чтобы посмотреть нагрузку отдельных виртуальных машин, можно использовать счетчик Hyper-V Hypervisor Virtual Processor\% Guest Run Time. Показания этих счетчиков можно толковать следующим образом: значения ниже 75% означают, что все в порядке, выше 75% – пора задуматься, а выше 85% означают, что нужно что-то предпринимать: либо устанавливать более мощные процессоры, либо каким-то образом снижать нагрузку.

    Память

    На хосте нужно следить за счетчиком Hyper-V Dynamic Memory Balancer\Available Memory, который показывает объем памяти, доступной для распределения между виртуальными машинами. Для отдельных виртуальных машин есть счетчик Hyper-V Dynamic Memory VM\ Physical Memory, отображающий объем памяти, фактически выделенный выбранной виртуальной машине (или нескольким – в зависимости от параметров счетчика). Кроме этого, можно обратить внимание на счетчики так называемой нагрузки (Memory Pressure). Нагрузка – это отношение объема памяти, который виртуальной машине требуется к тому объему, который был ей фактически выделен. Нагрузка измеряется в процентах, и значение должно быть ниже 80%. Значение от 80% до 100% должно заставлять задуматься, а выше 100% означает, что памяти явно недостаточно. «Среднюю температуру по больнице» показывает счетчик Hyper-V Dynamic Memory Balancer\Average Pressure, а для отдельных виртуальных машин существует счетчик Hyper-V Dynamic Memory VM\Average Pressure.

    Если у вас не используется Dynamic Memory – то прежде всего нужно обратить внимание на счетчик Memory\Commited Bytes, показывающий, какая из виртуальных машин сколько памяти фактически использует из выделенных ей. Если используется менее 90% выделенной памяти – то все в порядке. Если более 90% – то нужно посмотреть, не нужно ли добавить памяти, а может, где-то есть утечка памяти, или же неправильные настройки. А может, стоит добавить виртуальной машине еще памяти. Если же у виртуальной машины остается менее 100 Мб свободной памяти – то это означает, что срочно нужно что-то предпринимать.

    Диски

    Здесь нужно обратить внимание на счетчик \LogicalDisk(*)\Average Disk Sec\Read / Write. Этот счетчик показывает среднее время, затраченное на операции записи/чтения. Нормальное значение – ниже 10 миллисекунд (0,010). Значения до 15мс (0,015) и выше означают, что надо обратить внимание на дисковую подсистему, а значения, превышающие 25мс (0,025) говорят о критической ситуации. Чтобы определить, какая из виртуальных машин вызывает нагрузку – есть счетчики Hyper-V Virtual IDE Controller/Read/Write Bytes / Sec, показывающий количество считываемых или записываемых байт в секунду для каждого виртуального дискового контроллера. Более того, есть счетчик Hyper-V Virtual Storage Device/Read/Write Bytes / Sec, с помощью которого можно посмотреть количество байт в секунду для отдельных виртуальных дисков.

    Сеть

    Для оценки общего состояния сетевых интерфейсов имеется счетчик \Network Interface (*)\OutputQueue Length. Его значение не должно превышать 1, а значения выще 2 говорят о критической ситуации. Чтобы посмотреть, кто именно генерирует нагрузки на сетевой интерфейс – имеются группы счетчиков для виртуальных коммутаторов и для отдельных виртуальных сетевых адаптеров. Для виртуальных коммутаторов существует группа Hyper-V Virtual Switch. Из этой группы два счетчика: Bytes/Sec и Packets/Sec – показывают объем трафика, проходящего через виртуальный коммутатор, соответственно – в байтах и в пакетах в секунду. Для виртуальных сетевых адаптеров существуют группы счетчиков Hyper-V Virtual Network Adapter и Hyper-V Legacy Network Adapter. В этих группах параметры Bytes Sent/Sec и Bytes Received/Sec показывают объем передаваемого и принимаемого трафика в байтах в секунду.

    Заключение

    В этой статье я рассказал о том, как можно повысить производительность системы виртуализации на базе Hyper-V и о том, как за этой производительностью наблюдать. Если я что-то упустил, и у кого-то есть какие-либо идеи – с удовольствием их выслушаю.

Комментарии

  1. Черт возьми, прямо какой-то разгром Hyper-V по всем статьям 🙂

  2. Все-таки с те чтобы хост-ОС раотала в режиме Core, не совсем согласен. Объясняю почему: если с хостом будут проблемы, которые нельзя решить удаленно, то лучше иметь на нем инструментарий кроме PowerShell.

  3. @1
    А где разгром-то? 🙂

    @2
    Практически все инструменты и так есть: sconfig во-первых и powershell во-вторых. Ну и кроме этого есть инструменты сторонней разработки для управления сервером Server Core, в том числе и свободно-бесплатные (на CodePlex).

  4. В мониторинге дисковой предложено находить самую “прожорливую” виртуалку по счетчикам отражающим килобайты в секунду. На сколько я понимаю, толком по предложенным данным ничего не поймешь. Из опыта, большую нагрузку делают IOPS виртуалки, и для полноценного анализа нужно смотреть два графика и делать кореляцию результатов.

    А вот время отклика физического диска при записи/чтении – согласен, однозначно укажет на диск/массив который и стал “горлышком”.

  5. И еще хочу добавить по поводу “растущих” дисков виртуалок.
    Скзано что может снизить производительность из-за фрагментации и упомянуто про оптимизацию приложений для создания последовательной нагрузки на дисковую.

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

    зы
    тема влияния фрагментации вроде в блоге про netapp обсуждалась, там и тесты вроде были.

  6. Заработало только так:
    write-host (@(gwmi -ns rootvirtualization MSVM_Processor).count / (@(gwmi Win32_Processor) | measure -p NumberOfLogicalProcessors -sum).Sum) “virtual processor(s) per logical processor” -f yellow

    не те кавычки: «virtual processor (s) per logical processor»

  7. @6
    Ну да, копи-паста, блин 🙂 Сейчас исправлю.

    P.S. Я тут видел, кто-то вставлял в текст статьи исходники с красивым форматированием и подсветкой – подскажите чайнику, как это сделать 🙂

  8. “Microsoft считает, что если следовать Best Practices, и не запускать в хостовой ОС ничего кроме, собственно, Hyper-V – то хватит и 32 Мб, но я бы все же порекомендовал ставить 1 Гб. На всякий случай.”
    Например? Имеется случай из практики? Извините, но по моему, отдавать хосту ненужную ему память подобными объемами очень похоже на клинический случай.

  9. @8
    “Подобными объемами” – это 1 гиг? Я бы не сказал, что это аццки много. Я исхожу из того, что 512М – это минимальные требования для ОС Windows Server 2008. Поэтому 1 Гб будет оптимально. Вообще я видел, как все начинало жутко тормозить, когда виртуалки “съедали” всю имеющуюся память из-за DM, так что какой-то запас резервировать надо однозначно. Насчет объема можно поспорить, но почему-то я думаю, что 32М будет маловато.

  10. Ну… “почему-то думаю” это совсем не аргумент. На 8 гиговой тестмашине, с гиперкоре СП1, минус полгига-гиг достаточно(не аццки) много. Но вполне можно начать наблюдать тормоза, а не повышение производительности или лишиться возможности поставить еще 1 сервер. Я за пределы 600мб на хосте еще ни разу не вылезал.
    P.S. Тестирую(можно сказать что и учусь) на бесплатном гипере с июля и по сей день, перед возможным запуском в продакшн. Пока жуткие тормоза на 1-6 ВМ наблюдались в трех случаях – неумеренное потребление памяти неумеренным количеством виртуалок(с этим и так все понятно), обращения хоста к реальному локальному винту с находящимися там системными vhd(к примеру перекидывание или коипрование очередного дистрибутива гига на 2-4, но тут подозреваю в первую очередь драйвера чипсета АМД785) и “левая” служба на хосте загружающая проц по полной с минимальным приоритетом (dnet, если кому вдруг интересно)

  11. Можно добавить что все три случая под рекомендации бестпрактикс явно не попадают.

  12. Не забывайте про софтовый искази инициатор, про файловый кеш, про то что для тех же 10гбит адаптеров рекомендуется по 512мб на каждый адаптер…
    В общем то что у вас хватало 600мб, не значит что этого хватит всем и всегда

  13. Pan_2@LJ, ну я ж не рекомендую всем 600мб. Меня удивил 1гиг “на всякий случай”, автор предлагает обсудить тему, я спросил что за случай такой, а он сам не знает…
    Про искази и файл-кэш с интересом бы почитал “на всякий случай” (пока не попадалось на глаза такой информации ни в technet, ни в других источниках). Рекомендация в полгига на каждую 10гигабитку, простите, вызывает недоверие. Можно ссылку?

  14. Картинка в тему! 🙂

  15. Как подсчитать соотношение virtual processor(s) per logical processor для кластера, а не для одного конкретного физического хоста? Т.е. надо обойти все узлы кластера и вычислить среднее значение, хотя это не совсем правильно, т.к. некоторые узлы могут быть пустыми и тогда это соотношение ничего не даст. Может быть можно выдать несколько строк?

  16. Можно добавить что все три случая под рекомендации бестпрактикс явно не попадают.

  17. >Сколько же процессоров назначать виртуальным машинам? Hyper-V позволяет назначить каждой виртуальной машине максимум 4 процессора

    Вероятно, стоило бы добавить, что это поддерживаемое число виртуальных процессоров. Презентовать ВМ, при конфигурации ВМ должным образом, можно до 64 vCPU.

  18. Здравствуйте коллеги.
    Следуя рекомендации “Если у вас отказоустойчивый кластер и используется Live Migration – то желательно выделить на каждом узле кластера отдельный сетевой адаптер для трафика миграции.” как это сделать? Достаточно ли просто иметь на каждой ноде по отдельному адаптеру или где то надо указывать системе о том что Live Migration надо проводить именно по этому каналу?
    Спасибо.

  19. gluhubdg http://snat.co.uk/?post_type=topic&p=11993 ここで、ラフィク

  20. qhjnxsqm http://yogaheaters.com/ viagra coupon viagra coupon ここで、ラフィク

  21. Просадка, затирание, провисание повреждение герметичности (продувание, сквозняк) створок окна – все это типичное проявление, которое со временем проявляется во всех подряд металлопластиковых оконных рамах и дверях. И их следовательно нужно отлаживать (обслуживать), с тем чтобы избегнуть, в последующем, дорогого проведения ремонта.
    Это в целом как в машине услуга прохождения тех обследования : если к сроку не сменить масло, не ликвидировать стук или чужеродный шум – исходы могут быть грустными или иначе говоря катастрофическими. (как например замена масла однажды в год или раз в 10000 км. – обходится к примеру 957 грн. Однако ремонтные работы двигателя обходится 9557 грн.) У нас мастерят высокопроффесиональные мастера, они помогают разрешить любую затруднение и удовлетворить даже самого разборчивого клиента Заказывайте ремонт пластиковых окон киев у нас, у проффесионалов.

    Заказать регулировка окон у проффесионалов.

  22. fbkuuzzw http://valleyofshadowsanddreams.com/ viagra coupon viagra coupon ここで、ラフィク

  23. Wwwxxx Video. Punjabi Housewife Sex Video. http://pornonaft.net/ Www Desi Girl Nude Com. Hot Indian Mom Tube. Xxx Mms India.

  24. AnthonySonAnthonySon

  25. Armado’s the fish?” a place he BIRON Did so