I'm not too sure why truncating PR_SYS_STATUSNODES would help in this instance.

As for the thread dump, this shows the following at the bottom

--- Thread Dump Complete ---
2018-05-23 11:22:27,440 [tp-nio-8443-exec-118] [          ] [                    ] [] (ngineinterface.service.HttpAPI) ERROR finops-payroll.amazon.com|xx.xx.xx.xx  - xx.xx.xx.xx: com.pega.pegarules.pub.context.RequestorLockException
com.pega.pegarules.pub.context.RequestorLockException: Unable to synchronize on requestor H55CAFCA02A5B8C696A3AEEB3F11129C7 within 120 seconds: (thisThread = http-nio-8443-exec-118) (originally locked by = http-nio-8443-exec-114) (finally locked by = http-nio-8443-exec-114)

This (along with the java stack) suggests to me that this particular server is trying to run two requests by requestor H55CAFCA02A5B8C696A3AEEB3F11129C7. But it needs to synchronize access so thread http-nio-8443-exec-118 needs to wait for thread http-nio-8443-exec-114 to finish before it can proceed.

By default if this is more than 2 minutes this will generate the thread dumps. So I'm assuming whatever activities are being performed by thread http-nio-8443-exec-114 are taking longer than that time.

Is this a one off occurrence or are you seeing this regularly?

If it's happened a few times, are you seeing the same stack structure in the thread that has the requestor lock?

Is this the same Java stack on the locked thread?

In the instance provided in the log file, it appears to be taking time during a call to pyUniqueValuesGrid.

I believe this appears when you try to add a filter. If  the popup is building a checkbox list to selectively filter on and your grid contains a lot of records, then it may take some time to build that list.