Apa kinerja yang masuk akal untuk buku pedoman Ansible sederhana terhadap ~ 100 host?


11

Kami mulai melihat Kemungkinan untuk mengganti instalasi cfengine2 lama. Saya punya buku pedoman sederhana yang:

  • menyalin file sudoers
  • menyalin resolv.conf templated (diumpankan dengan data group_vars dan host_vars)
  • memeriksa beberapa layanan berjalan
  • memeriksa keberadaan pengguna lokal

Playbook membutuhkan lebih dari 4 menit waktu wallclock untuk berjalan melawan 97 mesin (semua terhubung melalui jaringan cepat 1gig atau 10gig, dengan latensi sub-1ms LAN) dan menghabiskan lebih dari 50% CPU pada memori 2-core 4G VM ketika saya sedang menjalankannya.

Dibutuhkan sekitar 11 detik untuk berjalan melawan satu mesin, dengan sekitar 4 detik waktu pengguna + sys CPU yang dikonsumsi, yang TBH tampaknya masih sedikit berlebihan untuk jumlah pekerjaan yang terlibat.

Bit yang jelas:

  • Saya telah mengaktifkan saluran pipa secara eksplisit di direktori playbook-dir ansible.cfg lokal
  • Saya memiliki caching fakta untuk jsonfile diaktifkan, ansible.cfg lokal yang sama
  • Saya memiliki garpu yang disetel ke 50, sama (saya telah mencoba nilai-nilai lain)
  • Saya yakin Ansible menggunakan SSH bukan Paramiko dan menggunakan soket kontrol gigih - Saya bisa melihat proses SSH dimulai dan bertahan selama proses.

Apakah tingkat kinerja ini normal atau ada yang salah dengan pengaturan saya? Bagaimana saya bisa menentukan apa, jika ya?

Sunting: Sampai Agustus 2017, kami masih melihat masalah ini. Versi yang mungkin adalah 2.2.1 dan ukuran playbook telah bertambah sekarang. Nomor terbaru:

  • 98 tuan rumah
  • ansible -m ping all memakan waktu nyata 4.6s, pengguna 3.2s, 2.5s sys kali
  • proses playbook penuh membutuhkan waktu 4 menit, menggunakan 100% pengguna dan ~ 35% CPU sistem saat melakukannya (pada server VM 2-core, 100% menjadi satu CPU penuh)
  • OS target sebagian besar adalah CentOS 7, beberapa CentOS 6
  • profiling tidak mengungkapkan hotspot tugas tertentu AFAICT

Meskipun playbook sekarang jauh lebih besar, saya masih tidak berpikir ada sesuatu di sana untuk membenarkan bahwa tingkat beban CPU pada server playbook - waktu wallclock, mungkin, tetapi server penempatan seharusnya sebagian besar tidak digunakan untuk sebagian besar proses, Sejauh yang saya bisa lihat, sebagian besar salinan file dan beberapa perluasan template.

Catatan kami membuat penggunaan host / groupvars cukup luas

Beberapa orang telah bertanya tentang profiling, ekor dari lari dengan profiling:

Tuesday 01 August 2017  16:02:24 +0100 (0:00:00.539)       0:06:22.991 ******** 
=============================================================================== 
yumrepo : centos repos -------------------------------------------------- 9.77s
sshd : copy CentOS 6 sshd config ---------------------------------------- 7.41s
sshd : copy CentOS 7 sshd config ---------------------------------------- 6.94s
core : ensure core packages are present --------------------------------- 6.28s
core : remove packages on VM guests ------------------------------------- 5.39s
resolv : stop NetworkManager changing resolv.conf ----------------------- 5.25s
yumrepo : epel6 gpg key ------------------------------------------------- 3.94s
yumrepo : epel7 gpg key ------------------------------------------------- 3.71s
yumrepo : nsg gpg key --------------------------------------------------- 3.57s
resolv : build resolv.conf ---------------------------------------------- 3.30s
yumrepo : nsg repo ------------------------------------------------------ 2.66s
resolv : check NetworkManager running ----------------------------------- 2.63s
yumrepo : psp repo ------------------------------------------------------ 2.62s
yumrepo : ucs repo ------------------------------------------------------ 2.44s
yumrepo : epel repo ----------------------------------------------------- 2.27s
resolv : check for nmcli ------------------------------------------------ 2.08s
core : remove various unwanted files ------------------------------------ 1.42s
telegraf : write telegraf.conf file ------------------------------------- 1.13s
core : copy sudoers in place -------------------------------------------- 0.94s
core : ensure sshd is running ------------------------------------------- 0.90s

4
Buat profiling dengan ANSIBLE_CALLBACK_WHITELIST=profile_tasksdan untuk debugging lebih menyeluruh ANSIBLE_DEBUG=1. Perhatikan juga pada kecepatan koneksi ssh awal.
Konstantin Suvorov

Setuju dengan komentar @KonstantinSuvorov - mungkin ada satu host di lot yang membutuhkan banyak waktu untuk tugas tertentu. Setelah Anda mengisolasi tugas dengan profile_tasks, Anda dapat memeriksa menjalankan tugas-tugas itu di host Anda dan melihat tugas mana yang paling lama. Anda juga dapat menjalankan tugas yang sepele, seperti "command: w" terhadap semua host untuk memastikan bahwa dibutuhkan waktu yang diharapkan.
andyhky

1
Periksa kelaparan entropi. watch cat /proc/sys/kernel/random/entropy_availsaat playbook sedang berjalan. Jika kurang dari 1.000, Anda memiliki masalah potensial; jika kurang dari mengatakan 64 dan tidak pulih, daripada Anda memiliki masalah kelaparan entropi yang jelas. (umum di beberapa lingkungan VM). Ini berlaku untuk server manajemen Anda dan juga node yang Anda kelola.
Cameron Kerr

Pada VM manajemen saya dengan RAM 4GB, saya memiliki forks = 20 dan pipelining = True. ansible -i all all -m pingmelawan lebih dari 300 host (kebanyakan VM) membutuhkan waktu kurang dari 1 menit. Apakah playbook Anda melakukan apa saja untuk mengubah pengguna (menjadi / sudo / dll.). Seperti apa kinerja '-m ping'? Saya akan, berdasarkan pengalaman, mengatakan Anda ingin memiliki lebih banyak memori untuk 50 garpu.
Cameron Kerr

apa sistem operasi target Anda?
xddsg

Jawaban:


1

di ansible.cfgset Anda yang berikut ini:

[defaults]

# profile each task
callback_whitelist = profile_tasks

# [don't validate host keys](http://docs.ansible.com/ansible/intro_configuration.html#host-key-checking)
host_key_checking = False

[ssh_connection]
pipelining = True

Juga, di buku pedoman Anda, tetapkan strategi sebagai 'gratis'

- hosts: all
  strategy: free
  tasks: [...]

Terakhir, nonaktifkan pengumpulan fakta di permainan Anda: gather_facts: false

Jika, setelah membuat profil, Anda melihat banyak hal ini:

TASK [pip foo]
ok: [10.192.197.252] => (item=ansible)
ok: [10.192.197.252] => (item=boto)
ok: [10.192.197.252] => (item=boto3)
ok: [10.192.197.252] => (item=passlib)
ok: [10.192.197.252] => (item=cryptography)

squash tindakan tersebut di ansible.cfgdalam [default]:

misalnya squash_actions = yum,pip,bar


Terima kasih balasannya. Kami sudah menggunakan strategi: gratis dan pengumpulan fakta saya khawatir adalah sesuatu yang dibutuhkan oleh buku pedoman, sehingga tidak benar-benar berfungsi. Seperti disebutkan dalam jawaban saya, saya sudah melakukan pipelining.
user53814

@ user53814 dengan profil diaktifkan, apa yang paling memakan waktu? dapatkah Anda memperbarui pertanyaan dengan versi yang mungkin Anda gunakan?
xddsg
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.