When I continuously insert/select/update a collection, one thread for each operation, the whole performance (opcount) drops when one of the shards' RAM is about used up.
The _id is increased from 0 for insert, and select/update operations are based on random _id. I know that the performance is doomed to drop. But I want to know the reasons.
1. Since MongoDB flushes data from memory to disk once a minute, although RAM is about used up, only some dirty data in the memory need to be flushed, right? We call the dirty data "new data". Since OS's memory management is used, LRU algorithm will free up memory space for new data, because the majority of the used memory is not fresh data and can be simply destroyed without losing any information. So, no more data swap is caused by insert when RAM is used up and I guess insert performance should NOT drop, but why did it??? Is it caused by cost of memory allocation (internal operation of insert) or just disk flush or something else???
2. I can understand that more disk read may be needed when the memory is near limitation, because the work set is larger than the memory size, so some of data will need be loaded from disk from time to time. When the ratio of working set size over the RAM size increases, the rate of disk read need grow as well, since more frequent data swap is needed. Is that right???
3. On the other hand, the non-optimized global lock of MongoDB will block read and other write operations when one write is slow or even blocked. So, I think when RAM is almost used up, more global lock caused by slow insert will further cause the whole read&write performance drop, right??? BTW, will read lock block write operations?

I also attache a test file here, and it is so appreciated that you can give me some help. You can quick jump to the "Observe the cluster" part to get direct information of my questions.