Debug a fatal error caused by memory exhaustion

Running our "Export all products to CSV" admin tool throws this after about 15
seconds:

[PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate
20480 bytes) in /wp-content/plugins/myplugin/includes/class-exporter.php on line 88]

CONTEXT: [line 88 is inside a loop using a single WP_Query with 'posts_per_page' => -1
to fetch all ~30,000 products at once, then looping through get_post_meta() calls for
each; SAVEQUERIES/WP_DEBUG is currently enabled on this staging site]

Diagnose this like a senior dev tracking down a real memory leak, in order:
1. Identify which limit is actually in effect: 268,435,456 bytes is 256MB, so check
   whether that's coming from `php.ini`'s `memory_limit`, or from WordPress's own
   `WP_MEMORY_LIMIT` / `WP_MAX_MEMORY_LIMIT` constants in `wp-config.php`, since
   WordPress applies its own cap on top of the server's and admin-side requests use
   `WP_MAX_MEMORY_LIMIT` specifically, which is often left at the WordPress default
   even when the server itself allows more.
2. Explain the real cause here: `posts_per_page => -1` loads all 30,000 post objects
   into memory simultaneously, and each subsequent `get_post_meta()` call populates the
   object cache further, so memory grows continuously through the loop rather than
   being released, even though each individual iteration looks cheap.
3. Fix it with batched querying instead of a memory limit increase as the primary fix:
   paginate through the export in chunks (e.g. 500 at a time), calling
   `wp_reset_postdata()` and periodically `wp_cache_flush()` between batches so the
   object cache doesn't accumulate all 30,000 posts' meta simultaneously.
4. Flag the specific edge case caused by the current environment: `SAVEQUERIES` being
   enabled (part of `WP_DEBUG` in some configs) makes `$wpdb->queries` store every
   query string, arguments, and stack trace for the entire request, which on a
   30,000-row export can itself consume tens of megabytes and make the problem look
   worse than it will be in production, so this should be confirmed off before judging
   the real memory footprint.
5. Only after batching is in place, if there's still headroom needed for legitimately
   large exports, raise `WP_MAX_MEMORY_LIMIT` in `wp-config.php` as a supplement, not a
   replacement, for the batching fix, since raising the limit alone just delays the
   same crash at a higher row count.

Replace the export logic, row counts, and error line with your actual case.