这种技术贴下还有水军啊： http://www.v2ex.com/member/loohawe/replies
V2 站的某些人真是有趣！

@serial 这么多天过去了，老子都懒得理你了，你还跟我逼逼。我只好粗口相待了，你个傻缺， asshole 大神。

@dzhou121 我觉得也没必要讲那么多了，有的人可能就是一根筋，要么是真的傻，要么就是故意吐槽来的。浪费时间讲太多没用的。

就 @serial

关于数据处理，这眼界也真是 [狭窄] 得令人无语，你做不到不代表别人做不到啊，
国外就不说了，公开资料来看国内的豆瓣就用 Python 重写 Spark 处理数据啊
https://www.douban.com/subject/10774736/


你自己慢慢看吧。如果非要抬性能的杠也没啥意思，你用啥觉得性能好就用啥呗，俗话说 u can u up 嘛。
在 Sun 没有收购 HotSpot 技术前， Java 性能也被人诟病，又如何，即便现在 C/C++程序员可能还对 Java 有偏见，
但并不影响开源社区用它去做分布式和大数据应用！

还有，代码写不好不要怪语言和编译器，多反思自己用的技术是不是很契合自己的应用场景，换句话说你用 C 撸了一堆所谓 [高效] 的代码，速度在优于 Python ，实现的玩意不值钱，有个逑用。

k8s 是好，不敢用啊…

可以写个简单的 agent 到应用服务器上收集状态信息发送到你的监控代理上，也可以由监控代理主动去请求应用的接口或页面做状态判断。
服务器监控的常见手段么，无非是： SNMP 、 WMI 、 HTTP Get 、 PING 等， lz 可以去了解下 Zabbix 等开源监控系统的架构

@dzhou121 终于有明白人粗来说话了～ 唉.

@liangmishi
看情况，假设你用的是 mysql ，如果是数据库表死锁了导致的，那么在解锁前你就查不了了。这跟 Python 、 django 框架没啥关系的。
还有种可能就是数据库连接资源被吃光了，无法释放多余的连接给你的 client ，发生这种情况就要找你们的 dba 看下查询提交状态了， kill 掉慢查询或重启……

@serial 你 bb 那么多能证明啥，证明你完虐 Python ，怒骂设计不合理 还是你智力有很高？ 傻逼

@serial 忘记 at 了

不管你说啥，俺就一个观点： [ IO 阻塞与否跟编程语言没多大关系的， OS 、各类服务 driver 不支持的话，众多编程语言一起哭吧]

没必要把一些库搬出来证明啥，其实啥也证明不了。也麻烦你仔细看俺跟你辩的到底是啥嘛。

ps:在网络上话多措辞强硬有得罪请见谅。希望接下来的辩论，不会让 v2 风气变得太差。
窃以为这种问题帖要学术些、实证些而非诡辩、争吵。伤人不太了。

@serial 放一堆链接有啥用，明眼人一看就知道你吐槽的东西根本就不在点子上
首先要搞懂操作系统基本知识、并发、异步基本的东西再辩吧。

不是贴的文字内容越多，越有道理的。

记得 celery 也是 >_<

unicodeobject 对应实现为：
static PyObject *
unicode__sizeof__(PyUnicodeObject *v)
{
return PyInt_FromSsize_t(sizeof(PyUnicodeObject) +
sizeof(Py_UNICODE) * (v->length + 1));
}

看了下代码，关于这个__sizeof__方法不同对象提供的方法不同，其中你要的 stringobject 的实现：

static PyObject *
string_sizeof(PyStringObject *v)
{
Py_ssize_t res;
res = PyStringObject_SIZE + v->ob_size * v->ob_type->tp_itemsize;
return PyInt_FromSsize_t(res);
}

其中 v->ob_size 是实际长度（ byte ），
PyStringObject_SIZE 相当于 sizeof(PyStringObject)，
tp_itemsize 为 sizeof(char)

代码版本： CPython 2.7.x

@justou 官方邮件组说不同平台返回结果可能不同