DL580 G7 дает только низкую производительность на процессоре (E7 4870)
У меня есть DL580 G7 с четырьмя E7 4870 и 128 ГБ оперативной памяти (восемь картриджей по 2x 8 ГБ каждый). Операционная система - Ubuntu 18.04. На pcie16 есть TITAN X и установлен обязательный p410i, но никакой другой периферии. Когда я тестирую эту систему, я получаю около 50% производительности, которую она должна дать. Например, это эталонный тест DL580G7 с немного более слабым процессором (E7 4850) и аналогичной настройкой.
Однако моя система может показывать только половину производительности в том же тесте. (Я получаю около 980 для процессора и 20000 многоядерности). Это не кажется правильным.
Тест показывает все 80 ядер и 128 ГБ ОЗУ, поэтому оборудование распознается правильно.
Я уже прошел контрольный список HP по настройке низкой задержки и соответствующим образом изменил BIOS. Все настройки мощности в ILO3 выставлены на максимальную производительность.
Ubuntu настроен на "регулятор производительности" на всех 80 ядрах. Я заметил, что даже когда я подвергал систему большой нагрузке (например, вычисление чисел на всех 80 ядрах при 100% использовании ЦП в течение нескольких часов), нагрев ЦП практически не меняется (они остаются на уровне 40 градусов), а вентиляторы не вращаются. вообще (они остаются на уровне 40%). Общая потребляемая мощность, отображаемая в ILO3, достигает 650 Вт, но я ожидаю, что она будет ближе к 1 кВт в стрессовых условиях. Меня это немного озадачило
Я уже пробовал разные версии BIOS. Исходный BIOS был выпущен 01.07.2013, что вызывало проблемы с производительностью и у других пользователей (такие отчеты можно найти в Интернете). Поэтому я понизил его до 12 марта 2012 г., и проблема осталась.
Также, когда я сравнивал производительность этой машины с моей предыдущей машиной (с i5 4460), я заметил падение одноядерной производительности в четыре раза в моих приложениях (для вещей, не требующих интенсивного ввода-вывода, таких как добавление большого количества векторы), что согласуется с результатами тестов, но падение производительности одного ядра вдвое было бы тем, чего я ожидал. Меня беспокоит только производительность процессора. Насколько я могу судить, RAID работает нормально, операции ввода-вывода соответствуют ожиданиям (но также могут пострадать из-за снижения производительности процессора).
Когда я выполняю cat / proc / cpuinfo в периоды стресса , Я вижу, что процессор работает на частоте 2,2 ГГц.
Пока что я еще не тестировал другую операционную систему. Я сделаю это, как только у меня появится возможность перезагрузить машину. Цепочка PREROUTING (политика ACCEPT 0 пакетов, 0 байтов) pkts bytes target prot opt in source destination ...
Ниже приведены мои правила ip6tables :
# ip6tables -t nat -L -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT all eth0 any anywhere 2001:470:4a71:f170::/64 to:fdde:ad00:beef:0:91f5:6dd4:e66f:cf5b
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 19 packets, 1936 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 19 packets, 1936 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all any eth0 fdde:ad00:beef::/64 anywhere
0 0 MASQUERADE udp any eth0 fd11:22::/64 anywhere
0 0 MASQUERADE tcp any eth0 fd11:22::/64 anywhere
Я вижу, что пакеты уходят через eth0 с использованием tshark . Вот один типичный пакет (полученный на интерфейсе wpan0 ):
221 480.196225356 fd11:22::703c:ef83:a03d:7e1b ? 2600:1f1c:c93:da00:76c2:1dbd:72c2:d063 TCP 94 [TCP Retransmission] 49998 ? 50000 [SYN] Seq=0 Win=9 Len=0 MSS=474 WS=1 SACK_PERM=1 TSval=2889901 TSecr=0
Я хочу, чтобы эти пакеты проходили через фильтр MASQUERADE, чтобы их исходные адреса были переписаны на IPv6-адрес хоста в сети Ethernet ( eth0 ). Однако этого не происходит, хотя я ожидал, что пакеты будут соответствовать правилам ip6tables. Фактически, пакет даже не соответствует ни одному из правил MASQUERADE (засвидетельствовано счетчиком pkts ). Я' Я не знаю, как это отладить --- знает ли кто-нибудь, почему эти пакеты не маскируются?
Что я пробовал:
- Удалить все записи
conntrack:conntrack -f ipv6 -D - Перезагрузите компьютер.
Спасибо за вашу помощь!
Изменить:
Вот еще один полезный вывод:
# ip6tables-save -c
# Generated by ip6tables-save v1.6.0 on Sun Sep 2 11:44:06 2018
*filter
:INPUT ACCEPT [1812:134308]
:FORWARD ACCEPT [22:1760]
:OUTPUT ACCEPT [1782:210084]
COMMIT
# Completed on Sun Sep 2 11:44:06 2018
# Generated by ip6tables-save v1.6.0 on Sun Sep 2 11:44:06 2018
*nat
:PREROUTING ACCEPT [1:137]
:INPUT ACCEPT [1:137]
:OUTPUT ACCEPT [41:5757]
:POSTROUTING ACCEPT [41:5757]
[0:0] -A PREROUTING -d 2001:470:4a71:f170::/64 -i eth0 -j DNAT --to-destination fdde:ad00:beef:0:91f5:6dd4:e66f:cf5b
[0:0] -A POSTROUTING -s fdde:ad00:beef::/64 -o eth0 -j MASQUERADE
[0:0] -A POSTROUTING -s fd11:22::/64 -o eth0 -p udp -j MASQUERADE
[0:0] -A POSTROUTING -s fd11:22::/64 -o eth0 -p tcp -j MASQUERADE
COMMIT
# Completed on Sun Sep 2 11:44:06 2018
# ip -6 link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether b8:27:eb:96:eb:75 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether b8:27:eb:c3:be:20 brd ff:ff:ff:ff:ff:ff
4: tap0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 06:8a:53:01:68:f2 brd ff:ff:ff:ff:ff:ff
5: wpan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 500
link/none
# ip -6 -brief address
lo UNKNOWN ::1/128
eth0 UP 2001:470:4a71:f000::11/64 fe80::ba27:ebff:fe96:eb75/64
wpan0 UNKNOWN fdde:ad00:beef:0:cc1e:c6e2:8252:e44b/64 fd11:22::1c4d:925:de45:9d30/64 fe80::1c4d:925:de45:9d30/64 fe80::2ccb:f19:edce:c49e/64
# ip -6 route
2001:470:4a71:f000::/64 dev eth0 proto kernel metric 256 pref medium
fd11:22::/64 dev wpan0 proto kernel metric 256 pref medium
fdde:ad00:beef::/64 dev wpan0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev wpan0 proto kernel metric 256 pref medium
default via 2001:470:4a71:f000::1 dev eth0 metric 1024 pref medium
Оказывается, это потому, что контрольная сумма TCP была неправильной (в стеке TCP хоста была ошибка). Очевидно, tshark не показывает это по умолчанию, но из-за этого ip6tables не маскирует исходный адрес.
Спасибо всем за попытку помочь. Что касается предложения kasperd, оказалось, что аналогичное решение работает в моих настройках (у меня / 60, а не / 48), поэтому я попытаюсь отойти от ip6tables.
Изменить: у меня настройка работает без NAT в настоящее время. Спасибо за предложение.
Хорошо, у меня была такая же проблема. Решение оказалось простым: просто запустите: "ip6tables -A FORWARD -m conntrack --ctstate ESTABLISHED, RELATED -j ACCEPT"
Проблема в том, что код ip6tables не загружает модуль conntrack по умолчанию, поэтому правила с отслеживанием состояния прозрачно
А для IPv6 не нужен NAT! бригада - иногда она вам НЕОБХОДИМА, например, если вы хотите запускать контейнеры Docker на AWS. Он не поддерживает DHCP PD, поэтому вы застряли с NAT.