MySQL cannot spawn a new operating system thread because the host has exhausted process or memory limits, triggering error 1135.
MySQL Error 1135: ER_CANT_CREATE_THREAD occurs when MySQL fails to create a new OS thread due to hitting system thread, PID, or RAM limits. Free server memory, raise ulimit -n/-u, or tune innodb_thread_concurrency to resolve the issue.
Can't create a new thread (errno %d); if you are not out
Error 1135 fires when the MySQL server asks the operating system for a new thread but the OS refuses. The accompanying message usually reads: "Can't create a new thread (errno XX); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug."<\/p>
The server fails to accept new client connections or spawn background workers.
High-traffic production databases often see this during load spikes, mis-configured limits, or memory leaks. Rapid mitigation is critical or the instance becomes unresponsive.<\/p>.
Operating systems enforce limits on the total number of processes or threads a user can own. When mysqld reaches that ceiling, any further pthread_create call fails, surfacing error 1135.<\/p>
Memory starvation can also trigger the error. If mysqld cannot allocate stack space for the thread, the OS denies the request even if thread counts remain below the limit.<\/p>
Mis-tuned MySQL variables such as thread_cache_size or innodb_thread_concurrency may exacerbate the condition by keeping idle threads alive.<\/p>
Immediate relief is freeing resources: close idle client sessions, kill runaway queries, or restart the instance during a maintenance window. Long-term fixes require raising OS limits or lowering MySQL concurrency settings.<\/p>
Check per-user thread limits with ulimit -a<\/code> on Linux or review maxproc<\/code>/maxthreads<\/code> on macOS. Increase values in /etc/security/limits.conf<\/code> or systemd service files, then restart MySQL.<\/p>
On Windows, confirm the server is not hitting non-interactive desktop heap limits; a reboot may be required.<\/p>
Common Scenarios and Solutions<\/h3>High connection spikes:<\/strong> Use connection pooling or set max_connections<\/code> to a sustainable value. Galaxy’s pooled query runner prevents client storms from overwhelming MySQL.<\/p>
Memory leaks:<\/strong> Profile RAM usage with pmap<\/code> or valgrind<\/code>. Upgrade to a patched MySQL version if leaks stem from known bugs.<\/p>
Docker limits:<\/strong> Ensure the container has adequate --pids-limit<\/code> and memory allocations. Amend compose files and redeploy.<\/p>
Best Practices to Avoid This Error<\/h3>Set OS thread and open-file limits well above peak demand. Automate checks with Prometheus or CloudWatch to alert when mysqld thread count nears 80% of the ceiling.<\/p>
Configure thread_cache_size<\/code> to reuse threads instead of spawning new ones. For OLTP workloads, values between 16 and 64 balance reuse and memory overhead.<\/p>
Galaxy helps by centralizing SQL execution. Fewer developers open ad-hoc sessions, reducing simultaneous connections and preventing thread exhaustion.<\/p>
Related Errors and Solutions<\/h3>MySQL Error 1203 - ER_TOO_MANY_USER_CONNECTIONS: Similar symptom but triggered at the MySQL layer instead of the OS. Lower max_user_connections<\/code> or pool connections.<\/p>
MySQL Error 1040 - ER_CON_COUNT_ERROR: Fires when max_connections is exceeded. Increase the variable or apply connection pooling.<\/p>
MySQL Error 2002 - Can't connect to local MySQL server: Appears when the server stops accepting sockets, often following 1135. Reboot or free resources.<\/p>
Low available RAM or over-commit settings make the kernel deny allocations.<\/p>
ulimit -a in the shell that starts mysqld. Look for "max user processes".<\/p>
.avif)
.avif){kind=logo}
