На тему NUMA в vmware написано относительно много статей, где даны рекомендации по конфигурированию виртуальной машины. В основном они касаются настройки процессора и даны соответствующие рекомендации. Однако когда я приступил к практическим тестам то выяснил, что не все так однозначно. Даже если все сделано согласно рекомендациям, и у вас достаточно свободных ресурсов (CPU, память), то производительность wide vm (виртуальная машина, которая выходит за пределы узла NUMA) может проседать. Виной тому - балансировка NUMA. Вернее - память, несбалансированная между NUMA-узлами. Да и прочитанные рекомендации по "ядро-на-сокет" тоже оказались не универсальными.
Сразу оговорюсь - по сути это не такая большая проблема, поскольку просадка производительности наблюдается лишь для приложений, которые умеют задействовать многопоточность. А вот например Corona Renderer не зависит от балансировки NUMA. Более того, тест, сделанный программой Corona 1.3 Benchmark не зависел также и от конфигурации "ядро-на-сокет".
Данная статья написана для тех, кто знаком с технологией NUMA и знает правила конфигурования ВМ. Если кто-то не ориентируется в данной технологии, но ему все же интересны мои эксперименты с конфигурацией "двухпроцессорный сервер с 12 ядрами" то предварительно рекомендую прочитать соответствующие материалы, на некоторые приведены ссылки в низу моей статьи.
Итак, что пишет про балансировку сама VMware: The intelligent, adaptive NUMA scheduling and memory placement policies in ESXi can manage all virtual machines transparently, so that administrators don’t need to deal with the complexity of balancing virtual
machines between nodes by hand (Performance Best Practices for VMware vSphere® 6.0). Если по-русски, то: NUMA сама знает как балансировать виртуальные машины и размещать их память между узлами NUMA, вмешиваться не надо. На мой взгляд - нужно было добавить "в большинстве случаев".
Сразу оговорюсь - по сути это не такая большая проблема, поскольку просадка производительности наблюдается лишь для приложений, которые умеют задействовать многопоточность. А вот например Corona Renderer не зависит от балансировки NUMA. Более того, тест, сделанный программой Corona 1.3 Benchmark не зависел также и от конфигурации "ядро-на-сокет".
Данная статья написана для тех, кто знаком с технологией NUMA и знает правила конфигурования ВМ. Если кто-то не ориентируется в данной технологии, но ему все же интересны мои эксперименты с конфигурацией "двухпроцессорный сервер с 12 ядрами" то предварительно рекомендую прочитать соответствующие материалы, на некоторые приведены ссылки в низу моей статьи.
Итак, что пишет про балансировку сама VMware: The intelligent, adaptive NUMA scheduling and memory placement policies in ESXi can manage all virtual machines transparently, so that administrators don’t need to deal with the complexity of balancing virtual
machines between nodes by hand (Performance Best Practices for VMware vSphere® 6.0). Если по-русски, то: NUMA сама знает как балансировать виртуальные машины и размещать их память между узлами NUMA, вмешиваться не надо. На мой взгляд - нужно было добавить "в большинстве случаев".
Итак, что же я выяснил экспериментальным путем.
Прежде всего - балансировка работает! В большинстве случаев. И она пытается разместить ВМ так, чтобы их память распределилась равномерно между нодами, притом действует она весьма активно. Также планировщик следит за соотношением локальной и удаленной памяти. Т.е. если ВМ по количеству процессоров не выходит за рамки одной ноды, то она старается чтобы вся память была локальной. Так вот основное наблюдение - производительность виртуальных машин на хосте ESXi может существенно зависеть от степени сбалансированности памяти.
И в зависимости от уровня сбалансированности я выделил три уровня конфигураций виртуальной машины:
1. Оптимальная
2. Не оптимальная
3. Не совсем оптимальная.
Оптимальная конфигурация обеспечивает максимальную производительность*. Но в тяжелых условиях, т.е. когда NUMA разбалансирована, идет активная балансировка и на одной из нод мало свободной памяти, даже ВМ с оптимальной конфигурацией проседает в производительности.
Не оптимальная - даже при полной сбалансированности, т.е. если на хосте всего одна ВМ, она демонстрирует около 50% производительности от максимума.
Не совсем оптимальная - в основном ВМ работает на 100% мощности, но при некоторых условиях (уровень сбалансированности, количество свободной памяти на нодах и т.д.) в которых "оптимальная" дает 100%, "не совсем оптимальная" может деградировать до 50% (примерно).
*Под максимальной производительностью понимается значение в тесте "CPU PhotoWorxx".
Критерий оптимальности - это число vNUMA (или VPD). Но обо всем по порядку.
Моя тестовая конфигурация - двухпроцессорный сервер c Intel Xeon E5-2695v2 2.40GHz с 12 ядрами на сокет, 256 Гб ОЗУ.
И в зависимости от уровня сбалансированности я выделил три уровня конфигураций виртуальной машины:
1. Оптимальная
2. Не оптимальная
3. Не совсем оптимальная.
Оптимальная конфигурация обеспечивает максимальную производительность*. Но в тяжелых условиях, т.е. когда NUMA разбалансирована, идет активная балансировка и на одной из нод мало свободной памяти, даже ВМ с оптимальной конфигурацией проседает в производительности.
Не оптимальная - даже при полной сбалансированности, т.е. если на хосте всего одна ВМ, она демонстрирует около 50% производительности от максимума.
Не совсем оптимальная - в основном ВМ работает на 100% мощности, но при некоторых условиях (уровень сбалансированности, количество свободной памяти на нодах и т.д.) в которых "оптимальная" дает 100%, "не совсем оптимальная" может деградировать до 50% (примерно).
*Под максимальной производительностью понимается значение в тесте "CPU PhotoWorxx".
Критерий оптимальности - это число vNUMA (или VPD). Но обо всем по порядку.
Моя тестовая конфигурация - двухпроцессорный сервер c Intel Xeon E5-2695v2 2.40GHz с 12 ядрами на сокет, 256 Гб ОЗУ.
Т.е. физический узел NUMA - 12 CPU (24 vCPU) 128 Гб ОЗУ.
Программы, с помощью которых проводил тестирование:
AIDA 64. В ней много тестов процессора, но самый полезный - тест CPU PhotoWorxx.
Corona 1.3 Benchmark.
Почему самый полезный - это тест CPU PhotoWorxx? А потому что как следует из описания CPU PhotoWorxx использует соответствующие расширения наборов команд x87, MMX, MMX+, 3DNow!, 3DNow!+, SSE, SSE2, SSSE3, SSE4.1, SSE4A, AVX, AVX2, и поддерживает NUMA, гиперпотоковость, мультипроцессоры (SMP) и многоядерность (CMP). Т.е. если что-то не так с NUMA, то он это покажет. А еще он выполняется не так быстро, т.е. его данные в какой-то мере усредненные.
Методика тестирования.
Прежде всего нам нужно видеть распределение памяти но узлам NUMA. В этом нам поможет esxtop.
1. Заходим на хост ESXi по SSH (например PuTTy)
2. Запускаем ESXTOP.
3. Для вывода статистики по памяти жмем m.
4. Для изменения полей f.
5. Чтобы увидеть NUMA жмем g. Одновременно можно убрать другие поля (нажимая например на b, k, l, o) и вывести информацию только по ВМ (SHIFT-V).
Методика тестирования.
Прежде всего нам нужно видеть распределение памяти но узлам NUMA. В этом нам поможет esxtop.
1. Заходим на хост ESXi по SSH (например PuTTy)
2. Запускаем ESXTOP.
3. Для вывода статистики по памяти жмем m.
4. Для изменения полей f.
5. Чтобы увидеть NUMA жмем g. Одновременно можно убрать другие поля (нажимая например на b, k, l, o) и вывести информацию только по ВМ (SHIFT-V).
1. NUMA - конфигурация NUMA. Первое значение означает количество памяти в NUMA узле, а второе, в скобочках – количество свободной памяти.
2. NHN - Номер NUMA узла
3. NMIG - Количество миграций виртуальной машины между NUMA узлами
4. NMREM - Количество удаленной памяти, используемой ВМ
5. NLMEM - Количество локальной памяти, используемой ВМ
6. N&L - Процентное соотношение между локальной и удаленной памятью
7. GST_ND(X ) - Количество выделенной памяти для ВМ на узле X
8. OVD_ND(X) - Количество памяти потраченной на накладные расходы на узле X.
9. MEMSZ - Объем сконфигурированной памяти ВМ. ВМ никогда не получит памяти более этого значения, а в большинстве случаев будет получать значительно меньше из за разделения страниц (page sharing), баллонного драйвера или свопа.
10. GRANT - Объем памяти, предоставленный ВМ. Память не предоставляется ВМ пока к ней не возникнет хотя бы одного обращения.
Примечание: количество миграций виртуальной машины между NUMA узлами отображается только несколько секунд.
На данном скриншоте видим как раз случай когда идет активная балансировка. Только что произошла миграция у ВМ с именем VCSA. Три ВМ разбалансированны - в графе N&L - (процентное соотношение между локальной и удаленной памятью) 18%, 33% и 45%. Еще одна - VM-CLI-3 почти сбалансирована, ее уровень 94%.
Также мы видим что у нас два узла NUMA (пункт 1) по 128 Гб (1310ХХ Мб), и в NODE 0 свободно лишь 15251 Мб. И виртуальные машины, память которых в данных момент активно балансируется, как раз расположены в NODE 0.
Смотрим по объему памяти у ВМ. VM-CLI-3 имеет 131073 Мб (128 Гб) сконфигурированной памяти (MEMSZ - пункт 9), при этом выделено - 110645 Мб (GRANT - пункт 10). При этом около 6000 Мб - это удаленная память, т.е. находится в NODE 1. Чем и обусловлено значение N&L - (процентное соотношение между локальной и удаленной памятью) 94%.
По VM-CLI: хотя она и показывает 100% в столбце N&L, но в данном случае это ничего не значит, поскольку ВМ расположена в двух нодах и вся память у нее локальная. Смотреть нужно на конкретные значения памяти в нодах: 9490 и 19679. В идеале значения должны быть более менее одинаковыми.
Итак подытожим. Несмотря на то, что на хосте свободно довольно много памяти (около 79000 Мб) виртуальные машины хоста работают в весьма тяжелых условиях.
Отсюда два вывода:
1. Лучше не создавать большие ВМ.
2. Если все же такая необходимость возникла, то необходимо как минимум знать конфигурацию NUMA. И желательно понимать как она работает.
Смоделировать такие тяжелые условия работы позволяет программа TestLimit, про которую я писал в прошлой статье Стресс тест ESXi (потребление памяти виртуальными машинами). Именно с ее помощью можно выделить (загрузить) внутри ВМ 110000 Мб ОЗУ.
Далее, что нам нужно, это знать конфигурацию vNUMA, т.е. как NUMA видит виртуальная машина.
1. Способ - утилита Coreinfo v3.31
Для запуска - запускаем командную строку, переходим в папку с программой, и вводим
2. NHN - Номер NUMA узла
3. NMIG - Количество миграций виртуальной машины между NUMA узлами
4. NMREM - Количество удаленной памяти, используемой ВМ
5. NLMEM - Количество локальной памяти, используемой ВМ
6. N&L - Процентное соотношение между локальной и удаленной памятью
7. GST_ND(X ) - Количество выделенной памяти для ВМ на узле X
8. OVD_ND(X) - Количество памяти потраченной на накладные расходы на узле X.
9. MEMSZ - Объем сконфигурированной памяти ВМ. ВМ никогда не получит памяти более этого значения, а в большинстве случаев будет получать значительно меньше из за разделения страниц (page sharing), баллонного драйвера или свопа.
10. GRANT - Объем памяти, предоставленный ВМ. Память не предоставляется ВМ пока к ней не возникнет хотя бы одного обращения.
Примечание: количество миграций виртуальной машины между NUMA узлами отображается только несколько секунд.
На данном скриншоте видим как раз случай когда идет активная балансировка. Только что произошла миграция у ВМ с именем VCSA. Три ВМ разбалансированны - в графе N&L - (процентное соотношение между локальной и удаленной памятью) 18%, 33% и 45%. Еще одна - VM-CLI-3 почти сбалансирована, ее уровень 94%.
Также мы видим что у нас два узла NUMA (пункт 1) по 128 Гб (1310ХХ Мб), и в NODE 0 свободно лишь 15251 Мб. И виртуальные машины, память которых в данных момент активно балансируется, как раз расположены в NODE 0.
Смотрим по объему памяти у ВМ. VM-CLI-3 имеет 131073 Мб (128 Гб) сконфигурированной памяти (MEMSZ - пункт 9), при этом выделено - 110645 Мб (GRANT - пункт 10). При этом около 6000 Мб - это удаленная память, т.е. находится в NODE 1. Чем и обусловлено значение N&L - (процентное соотношение между локальной и удаленной памятью) 94%.
По VM-CLI: хотя она и показывает 100% в столбце N&L, но в данном случае это ничего не значит, поскольку ВМ расположена в двух нодах и вся память у нее локальная. Смотреть нужно на конкретные значения памяти в нодах: 9490 и 19679. В идеале значения должны быть более менее одинаковыми.
Итак подытожим. Несмотря на то, что на хосте свободно довольно много памяти (около 79000 Мб) виртуальные машины хоста работают в весьма тяжелых условиях.
Отсюда два вывода:
1. Лучше не создавать большие ВМ.
2. Если все же такая необходимость возникла, то необходимо как минимум знать конфигурацию NUMA. И желательно понимать как она работает.
Смоделировать такие тяжелые условия работы позволяет программа TestLimit, про которую я писал в прошлой статье Стресс тест ESXi (потребление памяти виртуальными машинами). Именно с ее помощью можно выделить (загрузить) внутри ВМ 110000 Мб ОЗУ.
Далее, что нам нужно, это знать конфигурацию vNUMA, т.е. как NUMA видит виртуальная машина.
1. Способ - утилита Coreinfo v3.31
Для запуска - запускаем командную строку, переходим в папку с программой, и вводим
Ключ -n позволяет вывести только краткое распределение процессоров по нодам.
2. Лог файл виртуальной машины. Есть команда, которая позволяет вытаскивать необходимые данные, но у меня она не сработала:
Поэтому я отрывал лог файл. Опять же есть два способа.
Первый - скачать файл vmware.log из папки ВМ (при выключенной машине).
Второй - зайти непосредственно на хост через ESXi Embedded Host Clien (https://адрес/ui).
Во всех случаях мы видим 4 VPD по 6 процессоров, итого 24.
Т.е. 4 сокета по 6 ядер.
Внутри ОС
Ниже привожу таблицу с результатами тестов.
Некоторые значения округлены, некоторые тесты не проводил. Некоторые тесты напротив были проведены очень много раз (подряд, через интервалы времени, после выключения/перезагрузки).
Тесты чтения/записи памяти выполняются довольно быстро, поэтому у них и высокая погрешность.
Так сказать рабочая тетрадь.
Описание теста CPU PhotoWorxx я привел выше, описание остальных тестов процессора доступно на сайте AIDA64
Значения, которые приведены через "/" - это как раз случай, когда удалось воссоздать 50% просадку производительности у ВМ "не совсем оптимальной" конфигурации.
Какие же общие выводы можно сделать из данной таблице?
1. Тест CPU PhotoWorxx показывает максимальную производительность (53000) при конфигурации с 24 vCPU. При дальнейшем увеличении количества vCPU значения в данном тесте снижаются.
2. Другие тесты процессора программы AIDA64, а также тест Corona 1.3 Benchmark растут с увеличением количества процессоров, но после 24 vCPU совершенно не пропорционально увеличению процессоров. Очень непропорционально.
3. При не оптимальной конфигурации просадка производительности в тесте CPU PhotoWorxx коррелируется с уменьшением скорости чтения/записи памяти.
4. ВМ с 48 vCPU тестировалась в двух режимах - когда она жила вместе с другими ВМ (не очень нагруженными) и после миграции остальных ВМ на другой хост. Производительность выросла. Но опять же не очень значительно.
5. Правило "одно ядро на один процессор" не универсально. Более того в некоторых случаях данная конфигурация показывала 50% просадку производительности по сравнению с многоядерной конфигурацией. В частности из таблицы видно, что при 32 и 36 vCPU в конфигурации одно ядро на сокет ESXi создает три VPD, что составляет не оптимальную конфигурацию.
6. Использованные тесты не показали разницу в производительности между одноядерной* конфигурацией и многоядерной.
* - в случае если настройка "одно ядро на сокет" создает оптимальную конфигурацию.
Т.е. при 24 vCPU не обнаружилась разница между "1 ядро на сокет", "12 по 2" и "4 по 6".
7. Производительность зависит от числа виртуальных NUMA (VPD).
* нечетные конфигурации не оптимальны по умолчанию.
P.S.
Данная статья описывает поведение балансировки NUMA в VMware ESXi 6.0.
В версии 6.5. количество виртуальных сокетов больше не равно количеству vNUMA узлов, о чем можно почитать в статье под номером 1.
Раз уж затронул версии ESXi, то упомяну, что с версии 6.0. добавленная память (по технологии Hot Add) балансируется между узлами NUMA.
Но вот горячее добавление CPU по прежнему не доступно. Т.е. установка соответствующей галочки отключает NUMA.
Продолжение рассмотрения NUMA -
VMware ESXi 6.0. Влияние балансировки NUMA на производительность. Часть 2.
Статьи:
2. Лог файл виртуальной машины. Есть команда, которая позволяет вытаскивать необходимые данные, но у меня она не сработала:
Первый - скачать файл vmware.log из папки ВМ (при выключенной машине).
Второй - зайти непосредственно на хост через ESXi Embedded Host Clien (https://адрес/ui).
Во всех случаях мы видим 4 VPD по 6 процессоров, итого 24.
Т.е. 4 сокета по 6 ядер.
Внутри ОС
Ниже привожу таблицу с результатами тестов.
Некоторые значения округлены, некоторые тесты не проводил. Некоторые тесты напротив были проведены очень много раз (подряд, через интервалы времени, после выключения/перезагрузки).
Тесты чтения/записи памяти выполняются довольно быстро, поэтому у них и высокая погрешность.
Так сказать рабочая тетрадь.
Описание теста CPU PhotoWorxx я привел выше, описание остальных тестов процессора доступно на сайте AIDA64
Значения, которые приведены через "/" - это как раз случай, когда удалось воссоздать 50% просадку производительности у ВМ "не совсем оптимальной" конфигурации.
Конфигура-ция
| VPD |
CPU PhotoWorxx
| CPU ZLib | CPU AES |
Чтение
из памяти
| Запись в память | Копирование в памяти | Corona 1.3 |
|---|---|---|---|---|---|---|---|---|
| 12 (12 по 1) | 1 | 26300 | 456 | 16900 | 2100000 | |||
| 12 (6 по 2) | 6 | 26800 | 461 | 16900 | 2159000 | |||
| 16 (16 по 1) | 2 | 43000 | 609 | 21900 | 2700000 | |||
| 16 (8 по 2) | 8 | 43000 | 608 | 22000 | 2700000 | |||
| 16 (2 по 8) | 2 | 43000 | 2700000 | |||||
| 20 (20 по 1) | 2 | 48600 | 750 | 27000 | 3350000 | |||
| 20 (2 по 10) | 2 | 49100 | 757 | 27300 | 3400000 | |||
| 20 (4 по 5) | 4 | 48900 | 762 | 26700 | 3300000 | |||
| 20 (5 по 4) | 5 | 23000 | 750 | 22400 | 3350000 | |||
| 24 (24 по 1) | 2 | 53000 | 903 | 31600 | 94450 | 72000 | 82908 | |
| 24 (12 по 2) | 2 | 53000 | 895 | 32000 | 94100 | 72000 | 83000 | |
| 24 (6 по 4) | 6 | 53000/24500 | 900 | 31900 | 91660/47000 | 66200/27000 | 80400/36000 | 3980000 |
| 24 (4 по 6) | 4 | 53100 | 95500 | 72000 | 83000 | 39940000 | ||
| 24 (3 по 8) | 3 | 23600 | 898 | 28900 | 43000 | 23400 | 32500 | 39800000 |
| 24 (8 по 3) | 8 | 53300 | ||||||
| 25 (25 по 1) | 3 | 23900 | ||||||
| 32 (32 по 1) | 3 | 23113 | ||||||
| 32 (4 по 8) | 4 | 51363 | 94765 | 72042 | 44820000 | |||
| 32 (8 по 4) | 8 | 50666/23140 | ||||||
| 36 (36 по 1) | 3 | 22700 | 994 | 34870 | 48150 | 22380 | 30666 | |
| 36 (12 по 3) | 12 | 50433 | 1044 | 34700 | 94500 | 59000 | 75000 | 46820000 |
| 36 (6 по 6) | 6 | 49000 | 1053 | 35190 | 94019 | 66266 | 67600 | |
| 48 (48 по 1) | 4 | 44700 | 1074 | 35800 | 4870000 | |||
| 48 (48 по 1)* | 4 | 45200 | 1186 | 38180 | 5401300 | |||
| 48 (24 по 2) | 24 | 35800 | 1168 | 37600 | 80570 | 5208000 | ||
| 48 (12 по 4) | 12 | 46377 | 1152 | 38325 | 95882 | 5388130 |
Какие же общие выводы можно сделать из данной таблице?
1. Тест CPU PhotoWorxx показывает максимальную производительность (53000) при конфигурации с 24 vCPU. При дальнейшем увеличении количества vCPU значения в данном тесте снижаются.
2. Другие тесты процессора программы AIDA64, а также тест Corona 1.3 Benchmark растут с увеличением количества процессоров, но после 24 vCPU совершенно не пропорционально увеличению процессоров. Очень непропорционально.
3. При не оптимальной конфигурации просадка производительности в тесте CPU PhotoWorxx коррелируется с уменьшением скорости чтения/записи памяти.
4. ВМ с 48 vCPU тестировалась в двух режимах - когда она жила вместе с другими ВМ (не очень нагруженными) и после миграции остальных ВМ на другой хост. Производительность выросла. Но опять же не очень значительно.
5. Правило "одно ядро на один процессор" не универсально. Более того в некоторых случаях данная конфигурация показывала 50% просадку производительности по сравнению с многоядерной конфигурацией. В частности из таблицы видно, что при 32 и 36 vCPU в конфигурации одно ядро на сокет ESXi создает три VPD, что составляет не оптимальную конфигурацию.
6. Использованные тесты не показали разницу в производительности между одноядерной* конфигурацией и многоядерной.
* - в случае если настройка "одно ядро на сокет" создает оптимальную конфигурацию.
Т.е. при 24 vCPU не обнаружилась разница между "1 ядро на сокет", "12 по 2" и "4 по 6".
7. Производительность зависит от числа виртуальных NUMA (VPD).
Оптимальное число VPD для 12-ядерного процессора.
| VPD |
Конфигурация*
|
|---|---|
| 1 | оптимально |
| 2 | оптимально |
| 4 | оптимально |
| 6 | не совсем оптимально |
| 8 | не совсем оптимально |
| 12 | оптимально |
| 24 | не оптимально |
* нечетные конфигурации не оптимальны по умолчанию.
P.S.
Данная статья описывает поведение балансировки NUMA в VMware ESXi 6.0.
В версии 6.5. количество виртуальных сокетов больше не равно количеству vNUMA узлов, о чем можно почитать в статье под номером 1.
Раз уж затронул версии ESXi, то упомяну, что с версии 6.0. добавленная память (по технологии Hot Add) балансируется между узлами NUMA.
Но вот горячее добавление CPU по прежнему не доступно. Т.е. установка соответствующей галочки отключает NUMA.
Продолжение рассмотрения NUMA -
VMware ESXi 6.0. Влияние балансировки NUMA на производительность. Часть 2.
Статьи:
1. ОТВЯЗКА VNUMA ОТ КОЛИЧЕСТВА ЯДЕР В VSPHERE 6.5
(Перевод англоязычной статьи Френка Деннемана. Хоть название и про версию 6.5, но, тем не менее, в ней есть и теория про 6.0.)
2. NUMA для vCPU в vSphere 5
(перечень тонких настроек)
3. NUMA и что про него знает vSphere?
4. Число ядер на виртуальный процессор виртуальной машины в VMware vSphere - производительность.
5. Оптимизация работы виртуальной инфраструктуры на базе VMWare vSphere
(подробное описание работы шедулера по размещению vCPU ВМ).
6. VMware VROOM! Blog
(Перевод англоязычной статьи Френка Деннемана. Хоть название и про версию 6.5, но, тем не менее, в ней есть и теория про 6.0.)
2. NUMA для vCPU в vSphere 5
(перечень тонких настроек)
3. NUMA и что про него знает vSphere?
4. Число ядер на виртуальный процессор виртуальной машины в VMware vSphere - производительность.
5. Оптимизация работы виртуальной инфраструктуры на базе VMWare vSphere
(подробное описание работы шедулера по размещению vCPU ВМ).
6. VMware VROOM! Blog
Комментариев нет:
Отправить комментарий