This is expected QAS functionality. A soft lock occurs when a process has started a transaction or iteration on a database. Therefore a soft lock will occur when vasd is updating the cache.
During a soft lock, others can read the QAS database. Normally the soft lock happens a lot, but it is very quick. In order for vasd to write out the data to the database a hard lock is created (it starts a soft lock when the updates start, and only does the 'write' at the very end in a transaction, so very quick). Nothing outside vasd should have a soft lock for more than a split second.
We have seen issues where some processes get a long-lived soft lock. This usually is something like Top does a getpwent cycle, doesn't complete it, just stops calling vasd. So if it is sitting there with an open iteration into our DB, it is preventing QAS from getting a 'write' lock. Now vasd is only going to try for 1.5 seconds to get that 'write' lock, but while it is, nothing else can read the DB (although everything else then waits 3 seconds for the hard lock to go away). So the system will appear slow however vasd will not get updates.
If the softlocks are persistent and do not clear on their own the process can be safely killed as follows:
1) #cd to /var/opt/quest/vas/vasd
2) #fuser vas_ident.vdb
3) #ps <pid> (use pid listed from previous command)
4) if linked to a vasd process then
5) kill -9 <pid>
Repeat step 3 to 5 for each pid found in step 2, then restart the vasd process.