Of the memory use that might be tricky to associate with a process, check shared memory, Shmem in /proc/meminfo
tmpfs is likely in use and can be swapped out. /tmp and /run and probalby a few others. Total size of such file systems: df -h -t tmpfs
For shared memory APIs, both POSIX and System V, see man shm_overview Only certain applications use these, such as some databases. At least know they exist, so you can track down shared memory use that is not directly tmpfs.
Swap usage ratio by itself is a capacity planning input, not an immediately actionable condition. 7.6 GB paging space on a 62 GB memory system is not a lot, I would characterize this as a 60 GB memory system with a little buffer.
You stated that swap in and out rate was basically zero, this reflects a low memory demand over that time period.
swappiness=1 sets paging to a high cost relative to keeping file pages in memory. However, it is not infinite cost, swapping out is still allowed. Given the large amount free, 50% of total memory, we can assume relatively light demand for both. So the kernel gradually swaps pages out, might as well do some I/O while there is not a desperate need for it.
Summing up per-process memory will be frustrating given the weird ways the kernel does memory accounting. Consider instead, plan for capacity based on total use, and let the swapping happen as it kernel sees fit. You recorded 5 GB in use on a system with more than 10x that in memory, and no evidence of a performance problem. Absent a much bigger workload you have not described, there is not anything to do here.
And finally, there exist "better load average" metrics to measure real contention: pressure stall information. Sample /proc/pressure/memory and perhaps /proc/pressure/io in your host metrics. On this system with lots of free memory, I would expect very little "some" stalls on memory. And zero "full" counters, its not thrashing.
tmpfsin-memory file systems, will typically be sent to swap when deemed possible/necessary.