楼主你是不是用了64位编译？内存地址都超了，64下就得用__int64一个个遍历了

VOYAGER

@likuku 用CLUSTER的就要注意简单一句join foo.user_id = user.user_id这种千万级的数据，用完这辈子结果就能跑出来了。
可能只有SCI的连接方案（没试过）解决。
如果只是select/update一个表，倒是没啥大问题，只要注意ndb偶尔crash（log直接显示代码多少多少行有问题或干脆承认就是有个unknown bug会crash）时有个脚本负责花几十分钟冷重启就行了

DROPBOX都不支持，而且现在网盘单个文件尺寸限制太大

我记得电脑坏的那些日子这病倒好了

又得达菲鸡了

@ipconfiger RMQ很纠结，还碰到过这货CRASH的情况

但不敢切割成单个JOB来做，怕网络开销更大，分一定数量的批次来做就很好。RMQ+CELERY太需要折腾了。

PyCharm

Palemoon从来没碰到问题。TETE的PRIVATE BUILD应该也可以

现在往里面上传TXT都不能啊，服务崩了貌似

@beordle 115过去客户端不验证HASH，当时传上去SHA1根本不对，后来改善了。我原来用迅雷快传，没啥单文件限制，可后来限速搂钱了。
百度存大文件3.5-4G可能会文件不对，基本是第一次传上去，下下来HASH不对，重新传一遍还是秒传的，然后下新的HASH就对了。可能是CDN转存时候导致的。后来实在受不了，大文件分卷顺便加个恢复，WINRAR的恢复就足够了。

@beordle 这样带宽BALANCE成问题了，前提得带宽拉PT还有充分的余力。支持webdav的网盘好弄些，百度跟过去的115存在上传后损坏的情况，我是压RAR的恢复记录分卷上传的。
金山单个文件有大小限制？传大文件岂不是还要分片，好像以前GMAIL DRIVE这类的软件大文件分片后效率奇差。

尝试切换到3，但发现除非废弃现有2的代码，不然两种之间切换想死的心都有。

用ORM吧

@jasontse 所以不能回应此事，就当是其他DNS服务商的问题就好了

@awsx 存档而已，有些经典原盘归档啊，硬盘做种空间有限，老的资源反正赚不到上传了，归个档呗。

@SkyLanD 果断不能刷，VPS流量代价有点高了吧

其实对混PT的，这点网盘空间一点都不够。