Лига Сисадминов

Производительность процессора в значительной мере определяет быстродействие всей системы.

Поэтому споры между поклонниками AMD и Intel выходят далеко за рамки непосредственных характеристик комплектующих. Одним из полей сражений для подобного рода споров традиционно стали испытания в новых компьютерных играх.

Для испытаний системы были укомплектованы следующими компонентами:

• Материнская плата – MSI X570 Tomahawk для AMD и Z490 для Intel;

• Несколько вариантов накопителей

Corsair Force MP600 1Tb [PCIe 4.0],

WD Black SN750 1 Tb [PCIe 3.0],

Samsung 870 QVO 8Tb [SATA],

Western Digital WD120EMAZ 12 Tb;

• Процессоры - Ryzen 9 3900XT, Ryzen 5 3600, Ryzen 5 3400G и Intel Core i5-10600K Comet Lake.

Платформы AMD и Intel сконфигурированы с одним и тем же оборудованием, за исключением материнской платы и процессора. Это означает, что тот же графический процессор RTX 2080 Ti FE и тот же двухканальный комплект памяти DDR4-3200 с примененным XMP. Обе системы также используют загрузочные диски PCIe 3.0, хотя при разных свежих установках, как мы знаем, перенос установки AMD на систему Intel может повлиять на производительность.

Чтобы избежать предвзятости в нашем сравнении, мы тестируем эти четыре процессора с четырьмя твердотельными накопителями в семи тестах бенчмарк.

Бенчмарки:

Для синтетического теста, чтобы увидеть, влияет ли производительность процессора на что-либо в данных условиях, воспользуемся CrystalDiskMark.

Для последовательного чтения основное наблюдаемое отличие, заключается в том, что для диска PCIe 4.0 наличие платформы с поддержкой PCIe 4.0 обеспечивает более высокую производительность, как и следовало ожидать. Zen 2 также демонстрировал ускоренное последовательное чтение с низкой глубиной очереди даже на диске PCIe 3.0 по сравнению с Intel и Zen+, хотя разница составляет всего 12%.

Для случайного чтения наблюдается схожая картина. Единственное отличие заключается в том, что на диске SATA Intel действительно демонстрирует более высокие показатели случайного чтения с высокой глубиной очереди и количеством потоков, хотя при низких значениях размера очереди разницы не было.

При последовательной записи производительность одинакова для каждой платформы с небольшим преимуществом AMD, в то время как для случайной записи может быть довольно большой прирост производительности с AMD по сравнению с Intel с дисками PCIe. Однако, производительность в тестах бенчмарк не всегда напрямую коррелирует с реальной игровой производительностью.

Производительность в играх

Что же касается некоторых игр, картина выглядит следующим образом. На примере Horizon Zero Dawn можно наблюдать некоторое влияние используемого диска на время загрузки. Причем быстрые диски были на 30 процентов быстрее самых медленных. Но именно здесь заметно влияние скорости процессора на быстроту загрузки.

Ryzen 9 3900XT при использовании твердотельного накопителя PCIe был примерно на 11% быстрее, чем Ryzen 5 3600 и Core i5-10600K, которые показали аналогичные результаты. Однако показатели всех трех процессоров были похожи при загрузке с диска SATA. Как и ожидалось в такой ситуации, Ryzen не выигрывает от наличия PCIe 4.0.

Самое большое различие показывает Ryzen 5 3400G. Он заметно медленнее при загрузке уровня, по сравнению с другими процессорами, и это масштабировалось во всех четырех вариантах хранения.

Обращает на себя внимание 3-4 секундная задержка, которую дает Intel в сочетании с Western Digital WD120EMAZ 12 Tb – с другими накопителями различия были незаметны, но здесь проявились достаточно ярко.

Это говорит о том, что есть в данном случае операции загрузки, которые полностью привязаны к процессору, и на более слабом процессоре это приводит к более медленной загрузке, особенно, когда само запоминающее устройство работает медленно. Для этой игры не сам жесткий диск в конечном итоге ограничивает время загрузки в целом, некоторые этапы загрузки связаны с хранилищем, другие – с процессором, поэтому наличие быстрых компонентов для обеих задач является ключевым для загрузки.

The Outer Worlds - интересный пример сравнения времени загрузки AMD и Intel. Производительность Ryzen не сильно различалась, даже между Ryzen 5 3400G и Ryzen 9 3900XT, при этом Zen + APU был всего на пару секунд медленнее.

Однако загрузка этой игры на Core i5-10600K была значительно медленнее – она заняла в Intel в два раза больше времени по сравнению с AMD, при этом Intel не показала значительного увеличения производительности при загрузке с SSD по сравнению с жестким диском.

Это в очередной раз подтверждает, что процессоры Ryzen, как правило, имеют более быстрое взаимодействие ядер, чем Intel при декомпрессии, но это не полностью объясняет данное несоответствие. Замеры были произведены четырежды, и каждый раз обнаруживалось подобное отставание.

В Red Dead Redemption 2 неожиданно не наблюдается разницы во времени загрузки между любым из протестированных процессоров. По-прежнему существует разрыв в производительности между временем загрузки жесткого диска и SSD, но 3400G - который до сих пор был медленнее во всех других играх - работает в этой игре так же хорошо, как 10600K или 3900XT. В трех случаях из четырех Intel демонстрировал отставание от Ryzen 9 3900XT и Ryzen 5 3600

В Assassin’s Creed Odyssey наблюдается другая ситуация, когда на время загрузки больше влияет ЦП, чем устройство хранения, если вы не используете жесткий диск. В этом тесте Intel показывает пусть небольшое, но заметное отставание.

Заключение

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

Несмотря на не слишком большую выборку игр в сравнении, очевидно, что именно прирост производительности ЦП может дать значительное ускорение загрузки.

Процессоры Ryzen в очередной раз показали себя с лучшей стороны, тогда как Intel продемонстрировал далеко неоднозначные результаты.

Сам инцидент возник 18 июля 2013 и затронул 1,4; пользователей компании и заключался в следующем:

- во время инцидента при оплате с банковских карт в пользу Twilio пользователи не видели соответствующих изменений на своем балансовом счете;

- автоплатежи выполнялись несколько раз (так как баланс клиента в Twilio не обновлялся после оплаты);

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

- отчеты об использовании сервисов не доставлялись клиентам из-за того, что что биллинговая система (система выставления счетов) находилась в режиме оффлайн.

Развитие событий.

18.07.2013 08:35 UTC: из-за обрыва сетевого соединения с ведущим (master) узлом ведомые узлы выполнили переподключение и запустили процесс полной синхронизации одновременно.

18.07.2013 09:39 UTC: сервисы, использующие ведущий узел, начали отказывать из-за повышенной нагрузки на него.

18.07.2013 09:42 UTC: redis-master был перезапущен для того, чтобы справиться с нагрузкой.

18.07.2013 10:28 UTC: системы мониторинга Twilio зафиксировали аномалию в системе выставления счетов (ошибки платежей по картам и блокировки учетных записей пользователей). Затронуто было 1.1% пользователей. Проблемой начала заниматься дежурная команда инженеров.

18.07.2013 11:10 UTC: биллинговая система была отключена для избежания дальнейших ошибок обработки банковских карт.

18.07.2013 13:24 UTC: были разблокированы все затронутые учетные записи. Система выставления счетов оставалась в режиме оффлайн пока специалисты занимались поиском основной причины ошибки.

18.07.2013 18:58 UTC: биллинговая система была включена.

18.07.2013 19:36 UTC: системы мониторинга снова зафиксировали ошибочную обработку счетов, затронувшую еще 0.3% пользователей системы.Система выставления счетов была вновь остановлена, а заблокированные учетные записи - разблокированы.

18.07.2013 21:57 UTC: Twilio начал возврат денежных средств. Работа по возврату заняла следующие 24 часа.

19.07.2013 22:00 UTC: возврат ден. средств был завершен.

19.07.2013 22:30 UTC: всем затронутым учетным записям на счет было зачислена сумма в размере 10% от их трат за последние 30 работы в сервисе.

20.07.2013 02:30 UTC: система выставления счетов запускалась постепенно для учетных записей, разделенных на группы.

20.07.2013 03:14 UTC: биллинговая система была запущена для всех групп пользователей (процесс запуска был завершен).

20.07.2013 04:15 UTC: работоспособность всех систем была восстановлена.

Основная причина. Twilio использует СУБД Redis для хранения баланса учетных записей. Кластер реализован на одном ведущем (master) и нескольким ведомым (slave) узлам, распределенным по разным ЦОД. Обрыв соединения 18.07.2013 08:35 UTC привел к значительному падению производительности Redis и возникновению тайм-аутов взаимодействия между ведомыми и ведущими узлами. Деградация была настолько значительной, что связанные сервисы начали отказывать.

Дежурная группа из-за высокой нагрузки на кластер Redis приняла ошибочное решение о необходимости его перезагрузки, так как она привела к чтению ошибочного файла конфигурации. Из-за ошибки конфигурационного файла Redis принял решение выполнить восстановление из AOL файла (файл, содержащий лог всех операций), которого не существовало, вместо использования бинарного снимка файловой системы (snapshot). В связи с этим Redis удалил все сведения о балансе учетных записей. Кроме того некорректная конфигурация привела к тому, что Redis сам запустился в режиме ведомого (slave) узла, что привело к его работе в режиме "только на чтение" и не давало биллинговой системе изменять сведения о балансе учетных записей.

У учетных записей с небольшим балансом и подключенными автоплатежами после выполнения платной операции производилось автоматическое списание ден. средств с привязанных банковских карт.

Состояние счетов хранится в двух независимых реляционных базах даннных. Эти сведения впоследствии использовались для восстановления корректного состояния баланса на учетных записях.

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

Что было сделано. В процессе решения проблемы кластер Redis был полностью заменен. Ошибка в конфигурационном файле была выявлена и поправлена. Во избежание проблем в будущем практика перезагрузки ведущего узла Redis была прекращена. Теперь он заменяется одним из ведомых узлов.

Потеря сведений о платежах также была признана ошибочной в системе автоплатежей. Ее отказ был высокорисковым, приводящим к неверным платежам клиентов и блокировкам их учетных записей. Теперь в случае, если счета клиентов не существуют или не могут быть изменены система не выполняет списаний и не блокирует учетные записи. Кроме того биллинговая система теперь сверяется также с бухгалтерскими базами данных в реальном времени.