The documents you identified with no session are still in memory. Even after these document are removed from the open documents list they are still in memory. Only when your QVS's memory consumption approaches the working set thresholds or after a long duration of inactivity will the memory be released.
This is a constant complaint of mine for the QVS. The working set values, which provide to help you control memory consumption, work better than historically. Still, I'd expect the garbage collection processes to be much more proactive.
In the past, some QV Admins I've talked to would restart the QVS regularly to eliminate potential issues due to poor garbage collection.
It would be nice if there were a set of administrative setting, that would assist in better controlling when and how memory is reclaimed.
There is a setting that can be adjusted for the "Document Timeout" for the server as a whole:
The help for this page says:
Open documents take up valuable system resources (that is, memory space, RAM, is allocated) and should not be allowed to remain open when not in use. However, if a document is closed too quickly, the users may get longer delay times when accessing the document, because the server has to reopen it. This value controls for how long a document will be allowed to be unused before the QlikView Server (QVS) closes the document and reclaims the resources.
8 hours after last session has ended for a particular document before it is discarded from memory - that is a pretty long time usually...
The otther thing you are wondering about (but which doesn't seem to be part of your actual question) is CPU usage remaining above 60% even when noone is using any document (all documents showing 0 sessions in QMC, right?) In that case, you could use Task Manager to figure out what process is doing all this hard work.
My guess is that it may be the distribution service that is doing one or more reloads. If it isn't reloads, it may be QVS that is dealing with a document with a sub-optimal data model. At least that was what I got a while ago: CPU going to 100%, no response in the AP and a user trying to open new sessions that were all getting stuck without any means of recovery except for restarting the QVS service.