One server is slow to respond to ansible (but does) gather_facts

291 views
Skip to first unread message

John Harmon

unread,
Jul 17, 2018, 1:43:44 PM7/17/18
to Ansible Project
Just trying to track down what changed on a server.   I will run a playbook against 20-30 servers and all of them (configured the same with ansible) respond quickly to gather_facts; however, just one server takes its own sweet time to respond.  It wasn't this way at first, but changed in the patch couple of months.  Any ideas as to track down why it is doing that?  All other ssh connections to the server are responsive as expected....

Kai Stian Olstad

unread,
Jul 17, 2018, 2:11:31 PM7/17/18
to ansible...@googlegroups.com
In my experience this is always because of IO (some mount point gone
stale)
Gather facts is running a lot of different commands like df, lvm, mount,
swap, nfs and other network filesystems and many more.

You could login to the server a try different commands that list
information about IO and see if some of them takes time.

--
Kai Stian Olstad

Marcos Alano

unread,
Jul 17, 2018, 2:13:07 PM7/17/18
to ansible...@googlegroups.com
Could I suggest to execute an ad-hoc command using the "setup" module against this machine and do all the debug?

John Harmon

unread,
Sep 26, 2018, 6:36:03 PM9/26/18
to Ansible Project
Marcos,

I can execute an ad-hoc, but I don't know what you mean by "all the debug"--or how to do that.
If I run the following, it returns promptly:
root@ansible:/etc/ansible # ansible myserver -m debug
myserver
| SUCCESS => {
   
"msg": "Hello world!"
}

Kai,

I cannot find any IO issues on the server in regards to the things you specified.  LVM isn't involved, but NFS is.  It is connected to the same NFS server as all of my other servers.  In addition, I don't see any stale files, or mounts.  Things look normal on the server other than it taking longer to respond than my other servers.....    I am still digging into this to see if I can find the cause for the slow response.

S C Rigler

unread,
Sep 26, 2018, 7:14:40 PM9/26/18
to ansible...@googlegroups.com
Is normal ssh to the server slow or only with Ansible?

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/ec3e4242-9556-4b53-817f-0b5e586aba83%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

John Harmon

unread,
Sep 27, 2018, 1:24:02 PM9/27/18
to Ansible Project
On Wednesday, September 26, 2018 at 5:14:40 PM UTC-6, Steve R wrote:
Is normal ssh to the server slow or only with Ansible?


Normal SSH to the server is quick and responsive.   If I ssh from the ansible server it is even quicker than from my current location directly to the server (The ansible server is on the same network as the other server, so this makes sense).  Once the facts are gathered, everything else in an ansible playbook is speedy as any other server, it is just slow to gather facts.  If I exclude gathering facts it is as responsive as any other server.

Brian Coca

unread,
Sep 27, 2018, 1:40:13 PM9/27/18
to Ansible Project
You can use the 'subset' option in fact gathering to narrow down what
is being soo slow on that machine (likely culprits are hardware or
network), this often is a symptom of some problem with the server
being slow or unresponsive to some device query.


--
----------
Brian Coca

John Harmon

unread,
Sep 27, 2018, 4:03:11 PM9/27/18
to Ansible Project
ansible myserver -m setup -a 'gather_subset=hardware' is definitely the culprit.  Do you know of any way to break down the hardware subset to further narrow this down?

Brian Coca

unread,
Sep 27, 2018, 4:20:24 PM9/27/18
to Ansible Project
You can use ANSIBLE_DEBUG=1 and check the target's syslog to see which
commands are run and how long till 'next command', other than that is
is just debugging the setup module while executing it




--
----------
Brian Coca
Reply all
Reply to author
Forward
0 new messages