V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  lolizeppelin  ›  全部回复第 22 页 / 共 49 页
回复总数  980
1 ... 18  19  20  21  22  23  24  25  26  27 ... 49  
@aieike

自己 google 一下
你执行的 shell 函数,最终实现是 fork 了一次,阻塞 wait,所以卡住
改成 fork 两次,直接 os._exit(0), 给 pid 1 接管你的子进程就是
这和写守护进程的原理是一样的

所有的外部进程调用都是 fork exec 的组合,这是 linux 编程基础,只盯着 python 自然一头雾水
不要开线程去 直接 fork 两次 exec 就完事
你又不关心执行结果 不要开线程
2019-09-05 10:34:04 +08:00
回复了 liangxunli 创建的主题 PHP PHP 高并发处理
唯一可以做的,就是对一些内容变化少的接口加缓存

上 openrestry
2019-09-05 10:32:31 +08:00
回复了 liangxunli 创建的主题 PHP PHP 高并发处理
估计是做区块链的 量化交易平台
这个并发很正常,全是 api 请求

换语言什么的就算了,等你们换好了估计公司都不在了 233
出了问题也担不起,老老实实家机器别折腾了,免得背锅 233
2019-09-03 21:14:09 +08:00
回复了 nullboy 创建的主题 Linux 群晖这种小内存真的能挂 PT?
这伤个屁

最伤的应该是流媒体,播放的时候写缓存数据,大量的写,电影越大生成的缓存文件也越大
这部分不用内存盘,嘿嘿,保障写入量大大滴
群晖我不清楚,反正 jellfin 是这样的,估计群晖的流媒体也好不到哪去
2019-09-03 21:08:07 +08:00
回复了 Breadykid 创建的主题 MySQL 刚才,领导对我的 sql 提出了建议
2 和 3 的核心问题是一样的


查询过程无外乎


数据库 应用层
从硬盘读取数据——数据库解析数据——复制到网路层 ~~~~~~~~ 网络层复制到应用程序——应用程序解析


数据库开销
硬盘读取开销~解析开销~复制 /传输开销


应用层开销
解析开销~传输开销

这些省不了的开销,无非是放在哪里而已

用数据库解析, 数据库 cpu 消耗大,但是传输开销小
应用解析,数据库 cpu 小,应用服务器 cpu 开销大,传输开销大
但是数据量大起来以后,传输开销自然就不能忽视了

如果 group by/join 前的数据远远大于处理后,思考两点
1.应用层来 group/join,数据库计算量的虽然降低,但是好处是否会被大量传输抵消?
2.一定量级上数据库层的 group/join 的否效率是否远远好于应用层?
3.上述一定量级是如何判断?
4.数据库层的 group/join 是否能降低硬盘 IO ?
5.应用层 group/join 事务问题怎么解决


-------------------------------------------------------------------------------------
1.其他数据库要用函数索引,也需要索引函数对象,例如 index(int(column))
2.mysql 不能多核并行查询,这个是死穴,当然少量数据肯定比你自己做强多了
3.mysql 没有 hash join 和 merge join 稍微大的数据 join 起来肯定要死翘翘,但是少量数据又有索引肯定比应用层做好得多.
至于到底多少数据量算大这个嘛............
4.分表是下策,mysql 的表分区也是个残疾...上策嘛....换数据库!!

所以说!!早点换 PG,压根就不纠结这些问题...真要纠结这些问题的时候,就是你换大数据的时候!!
PG 一统江湖!
你读一下 zipfile 的源码就知道了

根本原因在于 zip 设计本身,每一个文件需要写在这个文件的前分配空间写一段校验信息,文件越多校验的块也越多,zip 的性能自然就差
加上 python 本来计算就慢,这种方式更放大了 python 的缺陷

文件数量多非常不适合用 zip,非要用 zip 不如调系统的解压工具解压
2019-09-02 14:49:00 +08:00
回复了 zhiwoda123 创建的主题 硬件 四万块买一个外星人游戏本值不值
@zhiwoda123
还没出啊 刚在 CJ 上展出过而已,你自己搜索 Y9000x
2019-09-02 14:39:04 +08:00
回复了 zhiwoda123 创建的主题 硬件 四万块买一个外星人游戏本值不值
Y9000X,还没出,配显卡坞. 我不信外星人散热能罩得住 I9+2080
2019-09-02 14:36:37 +08:00
回复了 zhiwoda123 创建的主题 硬件 四万块买一个外星人游戏本值不值
不值,散热跟不上的把

买联想那个新出的 I9 不带显卡, 然后雷电 3 外接显卡盒。
不都是扩展坞接多显示器么,还直接用笔记本键盘啊?
2019-09-02 14:16:46 +08:00
回复了 lolizeppelin 创建的主题 Python 求一个编译号的 Python 包 yappi 要 python3.6 的
发现 https://anaconda.org/可以下载
orz 真是救了老命了
楼上真是搞笑, 虚拟化用傻了?
一台机虚拟出 10 台是算例翻倍了还是 IO 翻倍了

没钱没机器还上分布式,你当做实验啊?
直接物理机都不够用, 还套一层虚拟化?
思路都是找时序型数据库
PG 正好有时序插件, 比专门的时序数据库差一点,但是功能上是标准的 sql
时序的数据? 装 pg 的 timescaledb 插件啊

不用自己弄分区和 BRIN 索引了
2019-08-29 13:34:46 +08:00
回复了 hujianxin 创建的主题 程序员 常用 Python 写命令行工具的朋友,你最常用的库是什么?
请使用 python 最牛逼的配置文件兼命令行库 oslo.config

openstack 出品,用过以后你再也不需要用其他命令行 /配置文件库了
没有,目前可以作为微服务参考的 python 项目只有 openstack
2019-08-07 18:27:08 +08:00
回复了 cz5424 创建的主题 Python 如何维护 socket 链接池
顺便,tcp 层维持链接不一定靠谱,最好在应用层心跳,基本上常用的服务器都有用于心跳检测的 PING 协议包
2019-08-07 18:23:53 +08:00
回复了 cz5424 创建的主题 Python 如何维护 socket 链接池
简单可以看看 python redis 的实现

rabbitmq 心跳抄 openstack 的 oslo_messaging,的做法自己处理下就行了

基本上就是
写个优先级锁(避免心跳抢占具体执行),每个 connection 都记录上次使用时间和心跳包时间,用于判断是否发心跳 /是否长期不用

一个线程 /协程专门用于心跳发送,顺便回收长时间不使用的 connection
2019-08-06 11:25:34 +08:00
回复了 kayseen 创建的主题 Python Python 封装通过的 celery 服务
请使用 oslo.messaging
1 ... 18  19  20  21  22  23  24  25  26  27 ... 49  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2714 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 32ms · UTC 13:03 · PVG 21:03 · LAX 06:03 · JFK 09:03
Developed with CodeLauncher
♥ Do have faith in what you're doing.