How can you optimize JMeter for generating high load with limited hardware?

Run tests in Non-GUI mode exclusively, since the GUI's rendering and live-updating listeners consume CPU and memory that directly competes with load-generation capacity - this alone is often the single biggest lever available.

Disable or remove heavyweight listeners like View Results Tree from the test plan used for actual load runs, since storing full request/response data per sample scales memory usage directly with the number of samples processed; rely on a lightweight result writer and post-run analysis instead.

Increase the JVM heap size allocated to JMeter (via the HEAP environment variable before launching, or editing the startup script) if memory pressure is the limiting factor, since JMeter's default heap allocation is often too small for high-thread-count tests and can trigger excessive garbage collection that itself becomes a bottleneck.

Prefer JSR223 with Groovy over BeanShell for any custom scripting, since BeanShell's per-execution interpretation overhead compounds significantly at high thread counts, while JSR223 compiles and caches scripts for reuse.

If a single machine's ceiling is still reached even after these optimizations, that's the signal to move to distributed (master-slave) testing rather than trying to further squeeze more threads out of one box, since at some point hardware capacity, not configuration, becomes the actual constraint.