Як я можу знайти причину величезної різниці у продуктивності між двома однаковими серверами Ubuntu?


9

Я запускаю два сервери Dell R410 в одній стійці центру обробки даних (за балансиром навантаження). Обидва мають однакову апаратну конфігурацію, запускають Ubuntu 10.4, встановлюють однакові пакети та запускають ті самі веб-сервери Java (без іншого навантаження), і я бачу істотну різницю в роботі між ними.

Різниця в продуктивності найбільш очевидна в середньому часі відгуку обох серверів (вимірюється в самій програмі Java, без мережевих затримок): один з них на 20-30% швидше, ніж інший, дуже послідовно.
Раніше я dstatз'ясовував, чи є більше контекстних комутаторів, IO, свопінгу чи чогось іншого, але я не бачу причин для різниці. При однаковому навантаженні (без заміни, практично без вводу-виводу) використання процесора та завантаження на одному сервері вище.

Таким чином, схоже, різниця пов'язана в основному з процесором, але хоча звичайний контрольний процесор, що використовує sysbench(при відключенні всіх інших навантажень), дав різницю, він становив лише 6%. Тож, можливо, це не тільки процесор, але і продуктивність пам'яті.

Поки я перевірив:

  • Ревізія прошивки для всіх компонентів (ідентична)
  • Налаштування BIOS (я робив дамп із використанням dmidecode, і це не показало відмінностей)
  • Я порівнював /proc/cpuinfo, різниці немає.
  • Я порівняв вихід cpufreq-info, немає різниці.
  • Параметри Java / JVM (однакова версія та параметри для обох систем)

Також я повністю замінив оперативну пам’ять кілька місяців тому, без жодного ефекту.

Я загубився. Що я можу зробити, щоб зрозуміти, що відбувається?

ОНОВЛЕННЯ : Так! Зараз обидва сервери працюють однаково. Це були "Power CRAP" налаштування, як jim_m_somewhere назвали їх у коментарях. Параметри BIOS для "Управління живленням" були на "Максимальній продуктивності" на швидкому сервері, а на "Активному контролері живлення" (налаштування за замовчуванням від Dell) на іншому. Очевидно, я забув, що встановив це налаштування два роки тому, і не робив цього на всіх серверах. Дякуємо всім за дуже корисний внесок!


2
Можливо, у вас несправна ОЗУ. Якщо ваша програма важка в мережі, це може бути все, що знаходиться в мережі.
Кайл

2
Чи можете ви порівняти "Попередні налаштування процесора" в BIOS? - може бути в змозі запустити команду ipmitool для цього? Чи однакова швидкість на ОЗП? Я припускаю, що ви перевірили, чи є резервна копія акумулятора на дисках / контролерах ... просто думаєте "вголос" ... Оперативна пам'ять обох ящиків однакова? зареєстровано чи не зареєстровано ... AH ... Ви перевіряли, що "живлення CRAP" - ACPI вимкнено на обох серверах?
jim_m_somawhere

2
якщо вони подають ті самі дані, чи відбувається балансування навантаження, яке відбувається з fw чи dns? як виглядає статистика мережі? Чи однакові також конфігурації Java? чи розмір купи Java однаковий? стріляючи в темряві на цьому.
au_stan

2
Чи справді конфігурація програмного забезпечення однакова? Наприклад, чи ввімкнено AppArmor на одній, а інший вимкнено? Також перевірте "dmesg" на наявність помилок.
Антон Коен

1
Ви перевіряли провідний кабель мережі, порт на комутаторі, а також бачите iops або перевіряєте стан жорсткого диска ... З повагою

Відповіді:


6

Дві ідеї, залежно від того, як далеко ви хочете піти з цим:

  1. Поміняйте диски обох серверів і перевірте, чи швидкість роботи залишається на апаратному забезпеченні чи рухається разом із програмним забезпеченням.

  2. Порівняйте вихід, /opt/dell/toolkit/bin/syscfg -o complete-bios-config.outякщо ви зможете якось обдурити цей пакет для встановлення.


Вихід dstat досить чітко показав, що різниця в продуктивності виникає і тоді, коли не відбувається жодного IO. Встановлення syscfg на Ubuntu 10.4 справді здається складним. Я порівняв вихід dmidecode вже, sysctl покаже більше? Можливо, це менше роботи з фотографіями кожного екрану BIOS та порівняння їх. Я можу спробувати це.
the.duckman

1
Замінюючи диски, я не мав намір досліджувати IO, а скоріше, якщо саме програмне забезпечення (неправильна) конфігурація викликає повільність (наприклад, непарний параметр ядра).
chutz

3

Більше можливостей для виведення та відмінності:

  • sysctl -a (переконайтесь, що налаштування ядра однакові)
  • cat / proc / перериває (Можливо, якась інша частина апаратури зіпсується?)
  • Список датчиків ipmitool (тривалий знімок, але перевірте наявність більш низьких різниць рівня, перегрівання, проблеми з напругою тощо)

Дякую, на жаль, жодної очевидної різниці у виведенні цих команд.
the.duckman

2
Усі відмінності очевидні, якщо порівнювати файли за допомогою програмного забезпечення . Будь ласка, зверніться до цього питання: Як я відрізняю два конфігураційні файли?
Skyhawk

3

Це здається, що це може бути відносно мене балансиром навантаження. Коли ви говорите "однакове навантаження", як ви це вимірюєте?
Ви безпосередньо орієнтуєте кожен сервер, застосовуючи пробне навантаження ізольовано?
або Ви застосовуєте деяке навантаження до балансира навантаження та дивитесь результати на обох серверах?

Якщо ви робите останнє (вимірюючи навантаження, розміщене на обох серверах через балансир навантаження), ваш балансир навантаження може не розподіляти навантаження рівномірно між серверами (20% перекос для пари серверів не рідкість, залежно від того, як ваш балансир навантаження вирішує, хто отримує, які запити), через що один сервер приймає більше навантаження і, отже, працює погано.

(Якщо ви безпосередньо орієнтуєте кожен сервер, ізольовано, не використовуючи балансир навантаження як посередника, і ви переконалися, що кожен компонент ідентичний (аж до версій виробника) між обома системами, то я втрачаю - Я не можу придумати будь-яку іншу вимірювану причину подібної різниці в продуктивності між ідентичними серверами)


Ви маєте рацію, це робить і наш балансир навантаження - це насправді особливість. Тож я вимірював багато способів, і так, я навіть "повторно" повторював однакові запити на кожному сервері окремо один раз. Але навіть просто помістити весь трафік на одному сервері на деякий час і порівняти час, необхідний кожному серверу для підготовки відповіді, дає ті ж результати, що і більш складні установки.
the.duckman

Хм - в такому випадку я офіційно наткнувся - якщо все справді ідентично (і ми, здається, досить добре підтвердили, що це так), ви повинні бути в межах розумної похибки щодо показників продуктивності (± 5-7%) - ви Ви бачите варіанти більш ніж удвічі більше, і я поняття не маю, чому: - /
voretaq7

3

Спробуйте кілька інструментів профілювання, або системне профілювання, як perf, або Java профілювання, як VisualVM .

За допомогою perf ви можете профайлювати або запущений процес Java за допомогою PID, або профіль порівняння. Подивіться на обидві системи, подивіться, де повільна система витрачає свій час.

apt-get install linux-tools-common linux-tools

Тоді щось на кшталт:

perf record -e cpu-cycles -p <pid>

або

perf record -a -g <benchmark command>

тоді

perf report

Кілька ідей, як системи можуть працювати по-різному:

Навколишнє середовище: Чи різняться температура повітря чи повітряний потік? Вони в стелажах? Я бачив, як системи працюють по-різному в різних положеннях стійок, викликаних вібрацією. На кожній стійці різні рівні вібрації. Це малоймовірно, враховуючи, що ви сказали, що майже не використовується введення-виведення. Але я бачив, як диски сповільнюються до 2 Мб / сек послідовних записів через вібрацію в частинах стійки.

Помилки обладнання: будь-яке обладнання може бути несправним. Використовуйте профілювання, щоб побачити, що повільно. Це може бути поганий процесор або чіпсет, радіатор не приєднаний належним чином, поза балансових вентиляторів, що викликає вібрацію, несправні вентилятори, навіть поганий блок живлення. Спробуйте поміняти речі, які легко поміняти.


1

Чому ніхто не запропонував "sysprof" ..?

Саме для цього він був розроблений.

Або ж друга думка ... спробуйте вставити деякі обмеження в /etc/security/limits.conf

Спробуйте обидва.

Якщо ви нічого не отримаєте .... у вас є проблема безпеки, швидше за все, або фізичний дефект.

див. також: Мій Linux-сервер "Кількість створених процесів" та "Контекстні комутатори" ростуть неймовірно швидко

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.