Here is my understanding of all of these components:
Michele is correct - the qvconnect64 process connects to the database. Typically, each qvb process will spawn a child qvconnect process to make a connection to your data sources.
Qvb is the Qlikview batch process that's tied to each distribution service task. A nice way to see which task each process is working on is to use a tool like Process Explorer and pull up the qvb process properties. The 'Image' tab will give you some information about the process working directory, which may help you determine which task it is working on (depending on how you have structured your environment).
QVS is the qlikview service, and you can expect to see high RAM utilization as it loads open document datasets into memory. This isn't related to the distribution service.
Hope this helps! The reference manual is a great resource as well.
A few things that may make the (lack of) collaboration between QlikView processes a bit more clear. I'm simplifying most of the items to make this post short and comprehensive.
- QVS.exe is the QlikView Server process - it will handle licensing, authorizations, the loading of documents for display in the AccessPoint (just that) and some other things. QVS.exe has it's own memory manager that will grab as much memory as possible and will not (often) release that memory. Even when there is no document loaded. Reasons of risk management I guess. Note that QVS.exe will not go beyond the High water mark defined in QMC (often 80% of all RAM)
- QDS.exe is the QlikView distribution service - it will handle all steps necessary to load-refresh-store and distribute QlikView documents. But all of this happens outside of the memory pool allocated by QVS.exe. Yes, you are reading that correctly: the unpredictable amount of memory needed to reload a large document will be allocated in whatever memory is left by QVS.exe and the OS. This is one of the reasons why QV Server and Publisher are often parked on different machines.
- The chain of (independent) processes at task trigger time is something like
QDS.exe -> QVB.exe -> QVConnectXX.exe.
QDS.exe will manage the task schedules and detect a task trigger. It will then launch (if allowed, there is a maximum number of simultaneous reload jobs) a QVB.exe process that loads a specific document in memory, executes the load script and stores the result in a temporary file. QVConnectXX.exe will be used on a simple CONNECT and whenever a set of rows is needed from a database table. When the reload finishes succesfully, QDS.exe will distribute the temporary file to its final location (usually the AccessPoint)
Each of these processes will try to allocate memory for itself. QVB.exe and QVConnectXX will often very rapidly release their allocated memory blocks.
- The behaviour of QVB.exe can be predicted more-or-less by observing a reload of the same document in QV Desktop. AFAIK QVB.exe consists of the reload engine embedded in QV desktop.
I didn't mention the QMC or the corresponding service QMS.exe, because they do not have a real responsability in all of this except defining and monitoring tasks and settings.
Another discussion about this item: http://community.qlik.com/message/695837#695837