wp user list consumes 20+ GB RAM on 740k users, never completes

[MaximeMichaud]

Bug Report

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Summary

While running wp user list on a production database with ~740k users, the process consumed 20+ GB of RAM, filled swap entirely, and had to be manually killed. The command never completed.

Steps to reproduce

1. Have a WordPress database with 500k+ users (common with WooCommerce or membership plugins).
2. Run wp user list.
3. Observe RAM usage climbing continuously until the system becomes unresponsive or the OOM killer fires.

Environment

OS:	Linux 7.0.6-1-cachyos #1 SMP PREEMPT_DYNAMIC Mon, 11 May 2026 15:10:22 +0000 x86_64
Shell:	
PHP binary:	/usr/bin/php8.4
PHP version:	8.4.21
php.ini used:	/etc/php/8.4/cli/php.ini
MySQL binary:	
MySQL version:	
SQL modes:	
WP-CLI root dir:	phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:	phar://wp-cli.phar/vendor
WP_CLI phar path:	phar:///usr/local/bin/wp
WP-CLI packages dir:	/root/.wp-cli/packages/
WP-CLI cache dir:	/root/.wp-cli/cache
WP-CLI global config:	
WP-CLI project config:	
WP-CLI version:	2.12.0

Results and impacts

Severity: High

Expected results: wp user list completes and outputs the user list, or fails gracefully with an error if the dataset is too large.

Actual results: PHP allocates 20+ GB of RAM (the entire system memory + swap), the machine freezes, and the process must be killed manually with kill -9.

Workaround

Pass --number=100 explicitly to limit results, or query the database directly with SQL:

SELECT ID, user_login FROM wp_users LIMIT 100;

Relevant diagnostics

Running with --debug is not practical as the process consumes all system memory before producing useful output.

From ps aux before killing the process:

root  3808631  5.4 21.3 27706340 6818676 ?  Ds  May18  9:43 php /usr/local/bin/wp --path=/var/www/html/wordpress user list --fields=ID,user_login --allow-root

VSZ: 27 GB, RSS: 6.5 GB, the rest in swap.

Possible solution

Add a default limit to the get_users() call in User_Command::list_(), or paginate internally in batches.