Русский
Русский
English
Статистика
Реклама

Oem

AMD представила серверные процессоры Ryzen Threadripper Pro, но они не будут продаваться в розницу

15.07.2020 12:10:08 | Автор: admin


Кроме десктопного рынка, AMD всерьёз рассчитывает захватить и серверный рынок. И вот вчера компания впервые анонсировала линейку процессоров для рабочих станций под новым брендом Ryzen Threadripper Pro. Однако следует отметить, что эти процессоры будут доступны только в составе готовых систем, и соответствующие потребительские материнские платы не будут выпускаться.

Набор продуктов от AMD в течение нескольких поколений включал процессоры Ryzen Pro и Ryzen Mobile Pro, в том числе варианты с поддержкой ECC. Можно было предположить, что в то время как у Ryzen был вариант Ryzen Pro, наиболее естественным вариантом для Threadripper будет линейка EPYC. Рынок серверов и рынок высокопроизводительных настольных компьютеров/рабочих станций всегда частично перекрывались, и до этого момента, если покупателю нужен был серверный дизайн, с ECC и проверкой программного обеспечения, он обращался к EPYC.

Сейчас AMD меняет положение вещей, выпуская Ryzen Threadripper Pro.

Процессоры Ryzen Threadripper Pro по функциям во многом соответствуют односокетным EPYC: восемь каналов памяти до DDR4-3200, 128 линий PCIe 4.0, поддержка RDIMM и LRDIMM, поддержка безопасного шифрования памяти, поддержка управляемости DASH и проверки согласованности образа операционной системы в рамках программы AMD Pro Business Ready.

Где Ryzen Threadripper Pro отличается, так это по количеству ядер, частотам и TDP. Судите сами.

AMD Ryzen Threadripper Pro
Ядра Базовая частота Турбо Чиплеты TDP DRAM
3995WX 64 / 128 2700 4200 8 + 1 280 Вт 8 x DDR4-3200
3975WX 32 / 64 3500 4200 4 + 1 280 Вт 8 x DDR4-3200
3955WX 16 / 32 3900 4300 2 + 1 280 Вт 8 x DDR4-3200
3945WX 12 / 24 4000 4300 2 + 1 280 Вт 8 x DDR4-3200

Существует также небольшая разница в поддержке DRAM TR Pro поддерживает до 2 ТБ, а EPYC поддерживает 4 ТБ. Все процессоры Ryzen Threadripper Pro выпускаются только для одного сокета.

У топового процессора 3995WX 64 ядра. Он выходит за рамки топового EPYC 7742 (225 Вт, 2,25 ГГц / 3,4 ГГц) и даже 7H12 (280 Вт, 2,6 ГГц / 3,3 ГГц), предлагая более высокую базовую частоту 2,7 ГГц и гораздо более высокую турбочастоту 4,2 ГГц для TDP 280 Вт.

Вот как выглядит сравнение Threadripper Pro, обычных Threadripper и Intel Xeon:



AMD говорит, что количество ядер и частотные конфигурации более оптимально удовлетворяют разные потребности лицензирования, то есть учитывают программное обеспечение с лицензиями на ядро (где рекомендуются высокочастотные модели с меньшим количеством ядер) или на сокет (где рекомендуется больше ядер).

Одним из интересных элементов Threadripper Pro является то, что он настроен только на OEM. Это означает, что покупателям нужно будет договариваться с Lenovo или другими компаниями, чтобы купить оборудование. На данный момент Lenovo собирается стать партнёром по запуску семейства TR Pro на семействе рабочих станций ThinkStation P620. Соответствующий анонс уже опубликован на официальном сайте.


ThinkStation P620

Lenovo будет предлагать P620 в различных вариантах, с объёмом памяти до 1 ТБ DRAM и двумя графическими процессорами RTX 8000 (или четырьмя графическими процессорами RTX 4000).

В Lenovo P620 процессор установлен в такой ориентации, чтобы помочь с воздушным потоком, но это также ограничивает гнездо только одним DIMM на канал, поэтому здесь поддержка максимум 1 ТБ памяти. Система будет использовать множество инноваций Lenovo ThinkStation, таких как легко заменяемые вентиляторы, приводы и тому подобное.



Задача P620 и подобного оборудования очень похожа на задачу EPYC заменить топовые рабочие станции и с одним, и с двумя процессорами. Lenovo планирует позиционировать P620 TR Pro для замены своих продуктов P520 (один сокет) и P720 (два сокета). Рабочая станция появится в продаже с конца сентября.

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

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

Это интересное решение AMD, поскольку Ryzen Threadripper Pro позиционируется против процессоров Intel серии Xeon W-3200 и Xeon W-2200. Некоторые из этих процессоров доступны в коробочном виде, а другие продаются потребителям в виде деталей, и для каждого есть ряд коммерческих материнских плат. Ответ AMD прост с их продуктовой линейкой они решили, что в ней нет места для новой категории розничных процессоров. Поэтому TR Pro и WRX80 пока будут доступны только для OEM-производителей. Если кто-то хочет купить TR Pro в розницу, сообщите об этом AMD.

Главным конкурентом AMD является линейка процессоров Intel для рабочих станций. Если вы не следили за действиями Intel, не беспокойтесь это довольно сильный бардак. Давайте разберём его поэтапно:

До того как Intel запустила Xeon Scalable, она предлагала варианты своей линейки процессоров E5-2600 в качестве моделей для рабочих станций, таких как E5-2687W v2/v3/v4. Эти сокеты были совместимы с высококачественными настольными процессорами Intel без ECC или могли использоваться в серверных материнских платах с проверкой ECC.

После этого Intel выпустила семейство Xeon W-2100 на базе Skylake и предлагающее до 18 ядер с четырёхканальной памятью. Они работают на высокопроизводительном десктопном сокете LGA2066, но требуют специальных серверных материнских плат (со специальными серверными чипсетами). Эти CPU позже обновили до Xeon W-2200 на ядре Cascade Lake.

Вместе с тем, у Intel были процессоры Xeon W-3100 и Xeon W-3200 для сокета LGA3647, что позволяло использовать шестиканальную память и предложить до 28 ядер. Intel даже предложила специальную модель W-3175X с возможностью разгона.

Потом в 2020 году Intel добавила в линейку своих рабочих станций семейство Xeon W-1200, используя потребительский сокет LGA1200, но опять же с материнскими платами только на серверном чипсете. Эти W-1200 фактически заменяют процессоры E-2300, а семейство Xeon E было законсервировано в Xeon W.

Кроме того, у Intel есть Xeon Scalable Cascade Lake, который тоже широко используется на рабочих станциях.

Аргумент AMD здесь заключается в том, что TR Pro будет конкурировать со всеми предложениями Intel Xeon W. Там, где у Intel более 80 различных опций для различных сокетов, AMD предлагает только четыре, которые покроют большую часть рынка, плюс Ryzen Pro для нижнего класса рабочих станций.

Естественно, AMD считает, что они вышли победителем, и так же, как 64-ядерный Threadripper 3990X был противопоставляется двум процессорам Xeon 8280, и AMD сделала то же самое с 3995WX:



Сравнение производительности в различных программах (кликабельно):



AMD не будет публиковать официальные цены для своих новых процессоров, поскольку они выпускаются только для OEM, так что здесь практически невозможно сравнить производительность из расчёта на доллар.

Кроме того, AMD не выдаёт эти процессоры для тестирования представителям прессы (это вполне естественно, учитывая отсутствие материнских плат в продаже), предлагая попросить Lenovo насчёт рабочей станции P620.



Подробнее..

Мониторинг БД Oracle с помощью OEM

30.10.2020 10:10:09 | Автор: admin
image

Привет! Меня зовут Александра, я работаю в команде тестирования производительности. В этой статье расскажу базовые сведения об OEM от Oracle. Статья будет полезна для тех, кто только знакомится с платформой, но и не только для них. Основная цель статьи помочь провести быстрый анализ производительности БД и поиск отправных точек для более глубокого анализа.
OEM (Oracle Enterprise Manager) платформа для управления БД. OEM предоставляет графический интерфейс для выполнения большого количества операций с базами данных: резервное копирование, просмотр аварийных журналов, графиков производительности.

Performance Home


На вкладке Performance Home можно увидеть основные графики утилизации БД.

Average Runnable Process


Этот график дает общее понимание использования CPU.

Показатель Описание
1 Instance Foreground CPU Отображает утилизацию CPU процессами текущего инстанса, напрямую запущенными клиентом, например выполнение запросов. Список событий ожидания текущего инстанса можно посмотреть в AWR-отчете
2 Instance Background CPU Отображает утилизацию CPU фоновыми процессами текущего инстанса, например LGWR. Список событий фонового процесса текущего инстанса можно посмотреть в AWR-отчете или в официальной документации Oracle
3 Non-database Host CPU Отображает утилизацию CPU процессами, не относящимися к текущему инстансу
4 Load Average Отображает среднюю длину очереди процессов, ожидающих выполнения
5 CPU Treads/CPU Cores Отображает лимит максимально возможного использования CPU

Average Active Sessions


Average Active Sessions отображает информацию в разрезе классов событий ожидания и утилизации CPU. Активные сессии представляют собой каждое подключение пользователя из какого-то процесса, находящегося в активном состоянии (то есть работают в настоящий момент) или в состоянии ожидания. Среднее количество активных сессий рассчитывается как результат деления суммы всех событий ожидания на временной интервал.
  • Если зафиксирован рост активных сессий, то должна расти пропускная способность (график Throughput).
  • Если Active Sessions превышает CPU Cores/CPU Threads, это свидетельствует о проблемах производительности.
  • Если зафиксирован рост времени отклика операций, но при этом активные сессии не превышают CPU, это значит, что узкое место не в CPU и нужно более детально смотреть, по каким классам события ожидания фиксируется рост, после чего можно на графике нажать на соответствующий класс и провалиться глубже в детализацию (откроется отчет ASH Active Session History).


Если на графике нажать кнопку Include Background, можно увидеть дополнительно статистику по фоновым процессам.
В Oracle есть такие классы события ожидания:
Класс события ожидания Описание
1 Cluster События ожидания, связанные с управлением кластером RAC (Real Cluster Application)
2 Queueing Содержит события, которые показывают задержки получения дополнительных данных в канальной среде. Время, затраченное в этих ожиданиях, указывает на неэффективность или другие проблемы в канале, что влияет на такие функции Oracle, как Oracle Streams, параллельные запросы или PL/SQL пакеты DBMS_PIPE
3 Network Сетевые события ожидания, включая события, возникающие во время обмена сообщениями по сети
4 Administrative Ожидание выполнения DBA-команд, например пересоздание индекса
5 Configuration Ожидания, вызванные неправильной конфигурацией ресурсов базы данных или экземпляра (например, недостаточный размер лог-файла)
6 Commit События ожидания фиксации. Включает в себя одно-единственное событие ожидания log file sync (событие ожидания синхронизации файлов журналов), которое вызывают выполняемые в базе данных операции фиксации
7 Application События ожидания, возникающие из-за кода приложения
8 Concurency Ожидает внутренних ресурсов базы данных
9 System I/O События ожидания системного ввода-вывода. Включает в себя события ожидания, связанные с фоновыми процессами ввода-вывода, в том числе событие db file parallel write (событие ожидания выполнения параллельной записи в файлы базы данных), которого ожидает фоновый процесс записи в базу данных, и события, связанные с чтением и записью в архивные журналы и журналы повторного выполнения
10 User I/O События ожидания пользовательского ввода-вывода. Включает в себя события ожидания, связанные с пользовательскими процессами ввода-вывода, в том числе db file sequential read (событие ожидания выполнения последовательного чтения из файлов базы данных) и db file scattered read (событие ожидания выполнения чтения из файлов базы данных вразброс)
11 Scheduler События ожидания планировщика, включает в себя события ожидания, связанные с работой приложения Resource Manager (диспетчер ресурсов)
12 Other Другие события ожидания, включает в себя разнородные события ожидания

Throughput


Раздел Throughput отображает пропускную способность. Пропускная способность базы данных измеряет объем работы, которую база данных выполняет за единицу времени.

Пики на графике Throughput должны соответствовать пикам на графике Average Active Sessions. Если заметен рост времени ожидания, необходимо убедиться, что увеличивается пропускная способность. Если пропускная способность низкая, а время ожидания растет необходимо изменить настройки БД.

I/O


Latency показывает задержку чтения блоков. Это разница между временем выполнения чтения и временем обработки чтения БД. Показатель должен стремиться к нулю.
Оптимальным считается значение до 10 мс. Этот график основной показатель производительности в этом блоке. Если зафиксирован рост времени задержки, нужно посмотреть, не растет ли количество I/O операций и их вес, также на рост Latency может влиять утилизация CPU.

Статистику по I/O можно смотреть в разрезе функций, в разрезе типов и в разрезе групп потребителей ресурсов (группы пользователей). Для этого на графике необходимо выбрать соответствующий Breakdown. Графики показывают количество I/O-операций в секунду и их вес в разрезе выбранного значения Breakdown. Для большей детализации можно провалиться глубже в статистику, выбрав соответствующее значение на графике или в легенде, и посмотреть статистику именно по выбранному значению.

I/O Function


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

Можно выделить следующие категории:
Категория Описание
1 Фоновые процессы Включают в себя ARCH, LGWR, DBWR (полный список фоновых процессов есть в документации)
2 Активность XML DB, Streams AQ, Data Pump, Recovery, RMAN
3 Тип I/O Включает прямую запись и чтение (в том числе чтение из кэша)
4 Другое Включает операции ввода/вывода управляющих файлов

I/O Type


Выводит статистику по тяжести операций ввода-вывода. Маленькими считаются операции, которые обрабатывают до 128 КБ. К большим операциям ввода-вывода относятся: сканирование таблиц и индексов, прямая загрузка данных, резервное копирование, восстановление и архивирование.


Consumer group


Дает представление об утилизации диска в разрезе групп пользователей: показывает, какая группа пользователей выполняет операции чтения и записи в определенный период. Включает в себя фоновые процессы.

Parallel Executions


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



Services


Службы на этом графике представляют собой группы приложений. Отображаются только сессии активных служб, находящиеся в ожидании в определенный момент времени. Например, служба SYS$USERS это установка пользовательского сеанса.


ASH Report


ASH Report (Active Session History) дает более подробную информацию по потреблению ресурсов. Чтобы перейти к графику, в меню Performance нужно выбрать пункт Performance Hub/ASH Report. Также перейти к ASH Report можно при выборе класса события ожидания на графике Average Active Session.


На графике можно выбрать признак, по которому хочется посмотреть статистику. Основные признаки:
  • События ожидания и группы событий ожидания.
  • Группы пользователей, пользователи, сервисы, инстансы.
  • SQL-запросы.

На графике выше можно увидеть, что с 02:00 до 02:24 наблюдается рост времени ожидания чтения с диска, превышающего количество процессоров в системе.
Помимо этого можно посмотреть статистику по SQL-запросам, перейдя на вкладку SQL Monitoring.

На этой вкладке отображается топ-100 запросов по выбранному критерию (например, продолжительность, последние запросы, распределение по DB Time, утилизация диска). Нажав на SQL ID, можно провалиться глубже в детализацию и посмотреть как сам запрос, так и план его выполнения и потребляемые ресурсы. Подробнее про план выполнения запросов можно почитать в статьях Методы доступа к данным в Oracle и Опыт и рекомендации по оптимизации SQL-запросов.
Рассмотрим ситуацию, возникшую во время проведения нагрузочного тестирования одного из сервисов.

На графике явно прослеживается рост времени ожидания сети в моменты запуска тестов. При более детальном рассмотрении в списке SQL-запросов был найден запрос, который утилизировал сеть. Он обращался по dblink к другой БД.


AWR


AWR (Automatic Workload Repository) дает подробную информацию о процессах, происходящих с БД в определенный период. Для построения AWR-отчета нужно выбрать пункт меню Performance/AWR/AWR Report. Также есть возможность сравнивать два временных промежутка. Для этого нужно выбрать пункт меню Performance/AWR/Compare Period Report.
Ниже будут описаны наиболее показательные разделы AWR-отчета, описание остальных разделов можно поискать в официальной документации.

Load Profile


Здесь отображается общая информация по тому, как была загружена БД за выбранный период.

Параметр Описание
1 DB Time(s) Сумма времени утилизации процессора и время ожидания (без простоя)
2 DB CPU(s) Нагрузка на процессор
3 Background CPU(s) Загрузка процессора фоновыми задачами
4 Redo size Объем чтения
5 Logical reads Среднее количество логических чтений блоков
6 Block changes Среднее значение измененных блоков
7 Physical reads Физическое чтение в блоках
8 Physical writes Количество записей в блоках
9 Read I/O requests Количество чтений
10 Write I/O requests Количество записей
11 Read I/O (MB) Объем чтения
12 Write I/O (MB) Объем записей
13 IM scan rows Количество строк в In-Memory Compression Units (IMCU), которые были доступны
14 Session Logical Read IM Чтения в In-Memory
15 User calls Пользовательские вызовы
16 Parses Разборы
17 Logons Количество входов
18 Excecutes Количество вызовов
19 Rollback Количество откатов данных
20 Transacions Количество транзакций

Instance Efficiency Percentages



Показатель Критерии
1 Buffer nowait Если показатель меньше 95%, значит, буферы data block buffer используются неправильно. Возможно, нужно увеличить data block buffer size
2 Buffer Hit Если показатель меньше 95%, значит, буферы data block buffer используются неправильно. Возможно, нужно увеличить data block buffer size
3 Library cache hit Если показатель меньше 95% нужно расширять shared pool (либо причина в bind-переменных)
4 Redo NOWAIT Если показатель меньше 95%, это говорит о проблеме в redo log buffer или redo log
5 Parse CPU to Parse Elapsd Показатель должен быть больше или равен 90%, тогда большинство процессов не ожидает ресурсов, что говорит о правильной работе базы данных
6 Non-Parse CPU Показатель должен приближаться к 100%, это значит, что большинство ресурсов CP используется в различных операциях, кроме parsing, что говорит о правильной работе базы данных. Если Non-Parse CPU низкий, значит, база много времени тратит на разбор запроса вместо реальной работы
7 In-memory sort Значение меньше 100 говорит о том, что сортировка идет через диск, а также есть потенциальные проблемы с PGA_AGGREGATE_TARGET,SORT_AREA_SIZE,HASH_AREA_SIZE и bitmap setting
8 Soft Parse Чем он выше, тем меньше у нас Hard Parse
9 Latch Hit Чем он выше, тем меньше мы ждем Latches (если он низкий у нас проблемы с CPU-Bound и Latches)

Top 10 Foreground Events by Total Wait Time


В разделе находится топ-10 событий, которые ожидали ресурсов дольше остальных.

При анализе необходимо обратить внимание на класс события ожидания. Если wait class System I/O, User I/O или Other, это нормально для БД. Если класс события ожидания Concurrency, это может свидетельствовать о проблемах.
Классы события ожидания можно посмотреть в разделе Wait Classes by Total Wait Time. В разделе находится статистика по классам события ожидания с сортировкой по времени ожидания.

Описание некоторых событий ожидания:
Событие ожидания Описание
1 DB CPU Отображает процессорное время, затраченное на пользовательские операции над БД. Это событие должно находиться на первом месте списка
2 db file sequential read Метрика сигнализирует, что пользовательский процесс не находит нужный блок в buffer cache, загружает его с диска в SGA и ждет физического ввода/вывода
3 db file scattered read Указывает на проблему с фулл-сканами, возможно, нужны индексы
4 read by other session Может говорить о том, что размер блока слишком большой или задержка (latency) слишком большая
5 enq TX row lock contention Событие возникает при ожидании блокировки строки для дальнейшей ее модификации DML-запросом. Если показатель больше 10%, необходимо разбираться в причинах. Более детальную информацию можно посмотреть в разделе Segments by Row Lock Waits, в котором есть сведения о том, какие таблицы были заблокированы и какими запросами
6 DB FILE SEQUENTIAL READ Если среднее значение параметра больше 100 мс, это может свидетельствовать о том, что диск работает медленно
7 LOG FILE SYNC Значение AVG WAIT более 20 мс может свидетельствовать о проблемах
8 DB FILE SCATTERED READ Если это событие выполняется возможно, имеет смысл создать дополнительные индексы. Для более подробной информации нужно перейти к разделу Segments By Physical Read, в котором находится информация по таблицам и индексам, в которых происходит физическое чтение
9 direct path read temp ИЛИ
direct path write temp
Эти события дают информацию по использованию временных файлов
10 Buffer Busy Wait Событие указывает на то, что несколько процессов пытаются обратиться к одному блоку памяти, то есть пока первый процесс работает с конкретным блоком памяти, остальные процессы находятся в статусе ожидания

Host CPU и Instance CPU


Здесь стоит обратить внимание на %Idle и %Total CPU. Если показатель %Idle низкий, а %Total CPU высокий, это может свидетельствовать о том, что процессор является узким местом.



Foreground Wait Class, Foreground Wait events и Background Wait Events


Показывают классы и события, которые провели в ожидании большего всего. Foreground Wait events дополняет информацию раздела Top 10 Foreground Events By Total Wait Time. Background Wait Events показывает детализацию по событиям ожидания фоновых процессов.




SQL statistics


Раздел содержит несколько таблиц со статистикой по SQL-запросам, отсортированным по определенному критерию.
Подробнее про оптимизацию запросов и примеры типичных проблем в запросах можно почитать в статье Проактивная оптимизация производительности БД Oracle.

Параметр Описание
1 SQL ordered by Elapsed Time Топ SQL-запросов по затраченному времени на их выполнение
2 SQL ordered by CPU Time Топ SQL-запросов по процессорному времени
3 SQL ordered by User I/O Wait Time Топ SQL-запросов по времени ожидания ввода/вывода для пользователя
4 SQL ordered by Gets Запросы к БД, упорядоченные по убыванию логических операций ввода/вывода. При анализе стоит учитывать, что для PL/SQL-процедур их количество прочитанных Buffer Gets будет состоять из суммы всех запросов в рамках этой процедуры
5 SQL ordered by Reads Этот раздел схож с предыдущим: в нем указываются все операции ввода/вывода, наиболее активно физически считывающие данные с жесткого диска. Именно на эти запросы и процессы надо обратить внимание, если система не справляется с объемом ввода/вывода
6 SQL ordered by Physical Reads (UnOptimized) В этом разделе выводятся неоптимизированные запросы. В Oracle неоптимизированными считаются все запросы, которые не обслуживаются DSFC или Exadata Cell Smart Flash Cache (ECSFC)
7 SQL ordered by Executions Наиболее часто выполняемые запросы
8 SQL ordered by Parse Calls Отображает количество попыток разбора SQL-запросов до его выполнения
9 SQL ordered by Sharable Memory Запросы, занимающие больший объем памяти общего пула SGA
10 SQL ordered by Version Count Здесь показано количество SQL-операторов экземпляров одного и того же оператора в разделяемом пуле
11 Complete List of SQL Text Показывает полный SQL-запрос, не только его хэш. В этой таблице можно найти неоптимальные запросы (например, запросы по всем столбцам таблицы select * from..., запросы с большим количеством like и т. п.)

Active Session History (ASH) Report



В данной таблице находятся самые тяжелые SQL запросы, на которые приходится наибольший процент активности и наибольшее время ожидания.

В таблице содержится статистика по запросам, на которые приходится наибольший процент выборочной активности и подробная информация о их плане выполнения. Вы можете использовать эту информацию, чтобы определить, какая часть выполнения SQL операторов значительно повлияла на затраченное время SQL оператора.
Подробнее..
Категории: Oracle , Oem , Блог компании tinkoff

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru