Android studio emulator/AVD very high disk load (Linux)

Question

I'm trying to use the android emulator coming with Android Studio (4.0) on Mint 18. Unfortunately as soon as I run a device, my disk sees heavy workload and I can't really tell why - it must be many small writes as I can see in nmon. This renders the whole emulation completely useless as the emulated device is not really responding any longer. It does not depend on which device I'm trying to emulate (Pixel/Pixel2/own HW).

What I can't see is, which files are affected and why. Even iotop only tells me that qemu-system-i386 is putting some workload on the disk but not where (of course).

The only thing I can tell is that all magic disappears if I start the device from commandline with the "-read-only"-Argument - then everything runs fine and fast. But that's not a solution anyway because it doesn't preserve changes on the emulated device.

Any ideas?

Answer 1

I totally agree with Raman's comment: too much disk write. When I am using the android studio( "version": "dev build","buildNumber":"203.7717.56.2031.7678000",) emulator, the process with highest real time "disk write" value in gnome's system monitor, can reach 40 or 50 MB/s, which is quite astonishing. 40 or 50 MB/s not only in the start or end of emulation, it also happens as long as I make any operation in virtual device(i.e., swiping, clicking, opening apps). (BTW, ubuntu 20.04, ryzen 4800h, 16GB 3200 ddr4 dual channel RAM, emulating pixel 4, android 11 x86 with google play). I am also trying to find out why.

May be you could reduce the "disk write" by disable quickboot snapshot? I disabled automatic snapshot, and take a snapshot manually. Then disabled the quickboot, and set the default boot option from "quickboot" to "boot from one specific saved snapshot". Please remember, after setting the cconfiguration, you must reboot your PC to validate the settings, otherwise the settings may or may not take effect, or you simply could not open emulation unless reboot. After rebooting, the "disk write" value drops down from 40 or 50 MB/s to a normal range, less than 1 MB/s in most of times. However, after rebooting, I could not read articles from official accounts in wechat app(from tencent company) in emulated android device. The articles are just stuck in loading status after clicking. So this setting may also affect some of normal functionalities.

https://developer.android.com/studio/run/emulator#snapshots

https://developer.android.com/studio/run/emulator#quickboot-troubleshooting

"Loading or saving a snapshot is a memory-intensive operation. If you do not have enough RAM free when a load or save operation begins, the operating system may swap the contents of RAM to the hard disk, which can greatly slow the operation. If you experience very slow snapshot loads or saves, you may be able to speed these operations by freeing RAM. Closing applications that are not essential for your work is a good way to free RAM."

For your description, "But that's not a solution anyway because it doesn't preserve changes on the emulated device." You could simply take a snapshot manually when you need to save, and set it as your boot snapshot.

Answer 2

I noticed it happened quite much for emulated devices with Google Play or Google Api images. Also, after waiting quite a while (let say 10 minutes), the phenomenon stops. What I do is to use, whenever possible, devices with low API levels, then with no Google Play image, and better, no Google Api at all. I also try to allocate quite a lot of ram to the emulated device (at least 3G). It is really astonishing how an emulated Android device with api level 15 is fast compared to a api level 30 or 31.