Sweet_Oranges的专栏

c++ double float 相等性判断

Sweet_Oranges — Thu, 16 Sep 2021 17:53:11 +0800

起因在c++开发中，double或者float类型判断相等性不能简单的用等于符号进行，一般会采用如下方式进行判断 static inline bool DoubleEqual(double a, double b) { return fabs(a - b) < std::numeric_limits::epsilon(); } 为了验证这个说法，我在机器上写了如下一段代码，结果竟然没有一次输出，貌似可以直接比较 double a = 0, b =

mysql 后台导入sql文件被kill

Sweet_Oranges — Thu, 19 Nov 2020 10:05:52 +0800

现象导入mysql大文件，用了nohup这些命令都不行，当终端关闭老是被kill。解决切换到root用户下执行nohup sudo -uroot bash nohup mysql -uroot -pxxxxx xxx < xx.sql &

lockfree ringbuffer queue 总结

Sweet_Oranges — Thu, 10 Sep 2020 12:23:32 +0800

之前在实现基于共享内存的lockfree ringbuffer queue时候有几点疑惑的地方，做一个总结。本人能力有限，如果有错误的地方，希望能够指出。 1.多进程中共享的内存和多线程中看见的内存是否一致？这个问题更多的是linux操作系统的理解，线程和进程其实都是基于clone系统调用生成的KSE，区别在于其共享内存的方式（写时复制）不一样。 2.c++的atmoic在共享内存上的操作？首先要保证原子变量分配在共享内存之上，c++的内存模型理论上能够work，建议使用gcc bulitin

js中的forEach 遇到 async await

Sweet_Oranges — Wed, 02 Sep 2020 11:37:44 +0800

好久好久没有写js了。。。。，有时候看见这样的代码 let ret = []; [xxx].forEach(async (item) => { let res = await xxxx ret.push[res] }); //处理ret 这样是不对的，forEach底层实现没有await每个回调，所以上面代码其实ret是空的。应该这样写 let tasks = [xxx].map((item) => { return Promise }); let r

记录一次线上pthread_cond_broadcast引发的性能问题

Sweet_Oranges — Fri, 21 Aug 2020 11:18:33 +0800

前言 pthread_mutex_lock是在多线程编程中必不可少的一个工具，其底层采用了futex实现，能够在用户态解决大部分的锁竞争，其性能是非常高效的。背景最近上线的一个多进程间消息队列就采用了pthread_mutex_lock和pthread_cond_t来实现pub sub模型。生产者在写入消息的时候，调用pthread_cond_broadcast来唤醒消费者。本来以为这样很完美，在测试环境也没有测出什么问题。然而上线后上游直接报ring buffer full，定位出下游.

c++ std::function 比 c function 慢

Sweet_Oranges — Wed, 29 Jul 2020 11:39:21 +0800

项目中大量使用functional来替代virtual函数，那么functor函数相对于c function带来的额外成本是多少呢？今天构造一个测试用例来测试下。g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28) 测试如下几种情况： 1.c function int _func(int a, int b) { return a + b; } 2.重载operator()的struct struct _struct { int operator()(i

高性能c++ string split实现

Sweet_Oranges — Wed, 22 Jul 2020 11:39:27 +0800

类似于string_view。测试：分别执行100000次，split耗时257329us, boost::split耗时679503 测试得知比boost::split方法大概快2倍。 void split(std::vector> &a, const std::string &line, const char sep) { const size_t size = line..

c++ 用 vector 替代map

Sweet_Oranges — Tue, 21 Jul 2020 10:30:13 +0800

当数据的key数量线性可控，且有一个不重复的hash 算法来定义key。尝试用vector来替代map 测试下性能 #include #include #include #include int main() { // std::map test; std::vector test(100, 0); f.

awk 字符串转时间戳

Sweet_Oranges — Fri, 17 Jul 2020 16:35:53 +0800

awk 字符串转时间戳写了很多遍了记录下 function strtotime(str) { fmt=sprintf("%s %s %s %s %s %s %s", substr(str, 0, 4), substr(str, 6, 2), substr(str, 9, 2), substr(str, 12, 2), substr(str, 15, 2), substr(str, 18, 2), substr(str, 21, 2)); return mktime(fmt); }

pthread mutex cond 进程间共享(PTHREAD_PROCESS_SHARED)性能探究

Sweet_Oranges — Thu, 09 Jul 2020 16:27:19 +0800

pthread中提供了pthread_mutex_t互斥锁和 pthread_cond_t条件变量，我们通常在同一进程不同线程中使用，很少在进程间使用，这次通过实现一个生产者解锁多个阻塞消费者的例子来展示下用法。由于pthread_mutex_t不提供通过名称来在进程间共享的功能，我们通过共享内存的方式来达到共享。注意的是要指定PTHREAD_PROCESS_SHARED struct SHM_Data { pthread_mutex_t mutex; pthread_con.

共享内存实现多进程低延迟队列 10us

Sweet_Oranges — Thu, 02 Jul 2020 13:26:05 +0800

起因之前的博客写过通过inotify 加文件的形式来实现多进程队列的文章。这种方式在通常情况下表现不错，但是这里存在一个问题就是当消费者过慢，会产生大量的击穿内核高速缓冲区io，导致消费者卡在读取数据的瓶颈上，无法使用负载均衡等手段来提高处理能力。为了解决上述问题，引入了共享内存，众所周知，这是所有ipc中最快的通信方式，从根本上解决这个问题。下面通过实现一个producer 和 consumer 程序，来展示我的设计思路。 producer 由于物理内存有限，生产者会使用一个环形缓冲区来.

struct char[0] 零长数组使用

Sweet_Oranges — Wed, 03 Jun 2020 18:22:44 +0800

在c中虽然支持了变长数组，但是在使用的时候还是会有诸多限制。分配在栈上，也就是不能返回变长数组的指针，同时还增加了栈溢出的风险，以下是几种不能使用的场景。不能使用extern声明的长度在struct members中定义长度在static变量中定义长度在函数定义中定义长度 extern int n; int A[n]; // invalid: ﬁle scope VLA extern int (*p2)[n];

linux inotify 触发点探秘

Sweet_Oranges — Mon, 01 Jun 2020 11:08:40 +0800

起因之前写过一篇通过inotify来实现高性能的文件队列的文章，对inotify触发的点有些疑问，到底是底层文件发生变化后才trigger event还是在write complete后才触发的event。有必要搞清楚这个问题。分析查看vfs write相关源码https://github.com/torvalds/linux/blob/master/fs/read_write.c static ssize_t __vfs_write(struct file *file, const cha

linux 有名信号量semaphore性能探究

Sweet_Oranges — Fri, 29 May 2020 11:15:59 +0800

起因最近想基于共享内存加有名信号量实现一个进程间的共享栈，来取代thrift, 优化下ipc的延迟。测试首先测试了下thrift消息传递的延迟，分别在client调用前和server（client server位于同一台机器）收到消息打印微秒 start end us 776912 777005 93 777152 777228 76 777340 777422 82 777502 777572 70 测试结果表明thrift一次通信大概需要80us的延迟。如果我们改为信号量来

muduo 中 has_no_destroy 模板

Sweet_Oranges — Mon, 27 Apr 2020 16:28:45 +0800

在学些muduo源码中，单例模式源码中有这么一段 namespace detail { // This doesn't detect inherited member functions! // http://stackoverflow.com/questions/1966362/sfinae-to-check-for-inherited-member-functions template&l...

基于swoole的websocket聊天室设计实现

Sweet_Oranges — Fri, 17 Apr 2020 09:38:44 +0800

php中就不能不知道swoole这个扩展了，有了这个扩展很多不可能就变成了可能。借助于swoole提供的websocket机制，实现一个websocket服务器其实非常简单，我们只需要关注如何正确的管理用户链接以及状态。实现要点：使用swoole_table 在进程间共享数据，用来存储房间号中的fd列表。处理订阅以及取消订阅的时候要加锁。（涉及到fd列表的反序列化）我们一起来看看...

c++ std::enable_shared_from_this 的作用

Sweet_Oranges — Thu, 16 Apr 2020 11:18:40 +0800

通常需要使用enable_shared_from_this的场景是我们在类内部通过std::bind生成functor函数传递给其他实例时（暴露了this），当其他实例调用functor函数时，该实例有可能已经被析构，引起异常。在日常c++编程中，为了更好的管理资源，我们通常借助c++的RAII机制实现的shared_ptr来达到对资源的自动管理。 class Test{ ...

超简单的分布式任务实现

Sweet_Oranges — Mon, 13 Apr 2020 10:04:44 +0800

为什么不用hadoop 我们目前的数据大多是时间序列并且有状态的数据，数据体积也在10个g以上，由于时间序列的关系，必须将某一类的数据按照时间顺序严格的绑定在一个map上。并且我们想我们的消费程序完全不需要改造来支持hadoop的map reduce模式。要求：消费者对上游无感。支持水平扩展。系统本身耗能（cpu，memory）低。实现： redis用来做任务中心。（rpop...

基于kafka原理单机高性能微秒级别队列改造

Sweet_Oranges — Fri, 10 Apr 2020 15:26:13 +0800

为什么不用kafka消息队列 kafka是我们日常生活中比较常见的消息队列，非常适合做消息的离线处理。但是在一些实时性要求比较高的场景下，消息自带的延迟是不可忍受的，我测试发现一条消息转发大概需要200ms,实际情况可能有所出入,但肯定是毫秒级别的。我们追求的目标是微秒级别。 kafka从设计上就是倾向于面向大众,满足大部分需求。当然满足这些要求的成本就是通过牺牲了性能。所以说kafka适合做...

stdbuf 解决实时输出问题

Sweet_Oranges — Thu, 26 Sep 2019 12:42:09 +0800

缓冲类型分为三种：无缓冲行缓冲全缓冲 stderr默认缓冲就是无缓冲。而stdout的缓冲类型与输出介质有关：屏幕或者终端：行缓冲重定向文件、管道：全缓冲一般情况下程序输出介质都是屏幕或者终端,采用的都是行缓冲，也就是实时输出。但是当程序输出介质为重定向文件或者管道时，内核为了性能优化，可能变成非实时的。究其原因也就是因为pipe的缓冲区问题。例子: tail -f ...