整个环境架构：
django框架+Mysql+Queue队列。开启一个线程从Mysql中每隔一段时间把数据load进入Queue中，有个api从queue中读取数据。
启动方式: nohup python manage.py 0.0.0.0:14000
某一天早上来发现，queue的size为0，数据库还存在大量的数据，但是就是不向queue中load数据了。查看端口情况，发现：
[user@s136 Server]$ lsof -i :14000
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 42027 user 3u IPv4 135455289 0t0 TCP s136:45914->s136:scotty-ft (ESTABLISHED)
python 42100 user 5u IPv4 118155864 0t0 TCP *:scotty-ft (LISTEN)
python 42100 user 6u IPv4 135457271 0t0 TCP s136:scotty-ft->s136:45914 (ESTABLISHED)
正常情况下应该是：
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 14785 user 5u IPv4 140025915 0t0 TCP *:scotty-ft (LISTEN)
可能的原因：
1，django框架的原因；
2，使用的原因；
不知道有没有人知道或者可能知道什么原因？
以及，这个原因应该如何定位？
"但是就是不向queue中load数据了",这里指的是向Queue中写数据还是读数据？
你用netstat看过RECV-Q和SEND-Q吗，是否TCP的缓冲区有消息排队？ socket本身是否有timeout? django是直接跑的还是挂载wsgi上跑的？
建议使用日志来排查问题。可以在你说的线程中，load数据前和之后都输出一条日志信息，这样就知道是未load还是在load的过程中阻塞了。
用GDB调试进程的方式来看看到底是卡在哪里了
参阅debuging with GDB
https://wiki.python.org/moin/DebuggingWi...