V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  laminux29  ›  全部回复第 62 页 / 共 119 页
回复总数  2366
1 ... 58  59  60  61  62  63  64  65  66  67 ... 119  
2021-01-30 11:00:49 +08:00
回复了 xiongya5555 创建的主题 Linux 容器 cpu 占有率为什么异常升高?
@BeautifulSoap
如果一定要掰字眼的话:
1.
Operating-system-level virtualization, also known as containerization, refers to an operating system feature in which the kernel allows the existence of multiple isolated user-space instances. Such instances, called containers,

Hogg, Scott (2014-05-26). "Software Containers: Used More Frequently than Most Realize". Network World. Network World, Inc. Retrieved 2015-07-09.

2.
To do this, containers take advantage of a form of operating system (OS) virtualization in which features of the OS

IBM Cloud Education (12 August 2019 ), "What are containers".
2021-01-30 08:46:04 +08:00
回复了 naoh1000 创建的主题 Linux 不暴露公网 Linux 使用 5 位数字做用户密码安全吗?
又要复杂,又要方便输入,这种需求,我觉得生物识别或便携式加密设备更适合。
2021-01-30 07:25:03 +08:00
回复了 LeeReamond 创建的主题 Python 想要使用 FastAPI 重构项目,应该如何快速入门?
@LeeReamond 我回帖前,一般会翻翻发帖人的发帖、回帖记录,来综合分析发帖人到底遇到过什么问题,以及他们的水平、偏好、思路、习惯等等,这对于猜测发帖人的真实需求很有帮助。

你的问题我基本上已经回答了,但对你没太大帮助,因为关键决策性的东西,你已经做了一两个月了,现在来更换很不现实。而且在本帖中,你需要的回答,是需要长期进行积累与试错的经验性的东西,这些东西别人没办法一步到位帮到你。不过这事的本质还是你使用了高风险高回报的激进策略。选择什么策略没有好坏,只是你要考虑能否接受策略失败后的风险。
2021-01-30 00:58:35 +08:00
回复了 xiongya5555 创建的主题 Linux 容器 cpu 占有率为什么异常升高?
虚拟化由于其兼容问题的复杂度过高,永远都没办法 100%稳定。

玩虚拟化,最好是找台同配置电脑或服务器,装 ESXi,拿来做参照基准,这样找问题会比较容易。

找问题时,多用快照甚至克隆。每当你对虚机做了一小个更改,立马保存一个版本。通过不断对比版本,你就能发现,哪次在什么地方,做了什么更改,导致系统突然变得不稳定,或者系统的 CPU 使用率突然增高。找到问题出处后,再去分析,才容易得到结论。
2021-01-30 00:54:04 +08:00
回复了 LeeReamond 创建的主题 Python 想要使用 FastAPI 重构项目,应该如何快速入门?
1.不建议选择 Oracle,这玩意是个烂心大苹果,不仅难用,麻烦,而且 D 版 bug 多,正版死贵用不起。现阶段建议使用微软的 MSSQL,基本上高端数据库该有的功能,它都有。

2.大内存服务器,你别只看着一线品牌全新款,那肯定死贵。洋垃圾 E7 + 国产 2 线主板 + 插满 128G 内存,也就 3 千不到,只是新手去买容易踩雷。

3.Python 属于胶水语言,你找模块,找组件,完全没必要只在 Python 框架下找组件。你可以直接去找 top 3,然后看看它支持什么语言,接着用 Python 甚至 DB 做中转。

复杂系统一般都是这样拆分的,比如 java 写业务,python 写爬虫,C++处理高性能数据计算,MSSQL 处理核心数据,redis 做热数据缓存,mongodb 做龟速大批量计算,然后利用 http 或 pb 或 db 做数据中转与传输等等。
1.开发的本质,是解决需求。只要需求被解决了,就是好产品。

2.如果公司只是经常做短平快的小型开发,不建议你过多去了解其他内容,容易跑偏。这种情况下,集中精力去解决需求会更好。

3.不过,一旦公司要开始做大中型系统,需求规模变大后,那么,解决需求的效率,以及产品自身的管理,会逐渐成为问题,这会牵扯出一堆管理问题。

软件工程就是这些管理问题的总结与经验,如果你是属于这种情况,建议找几本软件工程的教材好好看看,这些内容比较多,帖子里写不下。
2021-01-30 00:12:55 +08:00
回复了 zuoanyx 创建的主题 C 请问有人知道 c++里面 time(0) 获取时间会有异常的情况吗?
还有 std::clock()在虚拟化系统里经常出问题。

这两个问题的本质是,现在高阶 c++,时间处理方面,大多数转用 chrono 了,就算 chrono 有问题,因为用的人多,处理快,解决方案多。

而 time()、std::clock()这种,正好相反,现在基本上很少有人用了,更新后遗留 bug 或出问题,没人解决,也就很正常了。

IT 界这种问题很多,比如安卓,这系统一开始很烂,很多基本组件与功能都缺失。但是架不住用户多,各种缺失组件与功能,居然陆陆续续地被非官方开发者,解决地差不多了...
2021-01-30 00:04:20 +08:00
回复了 lbmjsls1 创建的主题 Linux 不同版本的 Linux 编译的 c/c++程序是否通用
就连高度统一的 Windows,在一个版本的 OS 上编译的程序,换个版本都有可能出问题,更何况 Linux 。

这个话题牵涉的东西太多了,可以讲好几天。

建议:
1.把主流的 Linux 版本,都编译一个版本出来,方便测试。

2.针对方便客户,甚至可以直接做一个配置好的虚拟化版本,方便客户测试。

3.如果客户的环境,和你们的预编译的所有版本都不一样,你可以建议客户,把他们的系统发给你们,可以是光盘、镜像文件、甚至整个虚拟机的打包。你们针对客户的系统版本,出个编译版本。
@djs

1.同事是好男人,但没女朋友,这事本质原因,是你需要加强对人的识别。

2.无论对于男女,只要 TA 优质,是不缺追求对象的。

3.优质的人,没有对象,大概率是想高攀,通俗来说就是 TA 看得上的人,看不上 TA ;能看上 TA 的,TA 又看不上。

小概率,是 TA 已经有了对象,但还想等等看,有没有可能找到更好的,因此对外一律宣称自己单身。

无论是高攀还是骗人,当事人都算不上是优质。
2021-01-29 23:05:21 +08:00
回复了 hjosama 创建的主题 程序员 女装大佬求职问题
非主流的奇怪爱好,是很费资源的,这些资源可不仅仅只是钱,还有可能是社会资源,职业前景等等。

自己衡量一下取舍吧。

当你有钱后,自己躲在家里,也可以适当享受一下爱好。找个平衡点,不香嘛?
@oooolongtea

你要换位思考一下,假设你是 HR,面试者的算法无敌,其他基础常识却需要补习,你会选择通过这样的人吗?

如果你开绿灯,这种人在公司写出大 bug,你作为 HR 也是有责任的。
2021-01-29 22:11:47 +08:00
回复了 orangeChu 创建的主题 程序员 关于分布式缓存,有点疑问,不吝赐教
@orangeChu

你嫌弃 redis 与 memcached 速度慢,具体是指:

api 调用延迟高?

还是每秒吞吐量低?
从你 81 天前,发的这个帖子 [https://www.v2ex.com/t/723035] 来看,我不觉得你的技术有你自称的 [85/100] 。

知识欠缺 + 自负,才是你面试失败的主要原因吧。
找女朋友的知识点,在婚恋方向。这个论坛主要讨论计算机技术,你在这里发牢骚没啥用,解决不了问题。
2021-01-29 02:03:29 +08:00
回复了 orangeChu 创建的主题 程序员 关于分布式缓存,有点疑问,不吝赐教
为什么要用分布式缓存?
1 ... 58  59  60  61  62  63  64  65  66  67 ... 119  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   2092 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 39ms · UTC 12:45 · PVG 20:45 · LAX 05:45 · JFK 08:45
Developed with CodeLauncher
♥ Do have faith in what you're doing.