小编red*_*ver的帖子

我有一个用C++编写的服务器应用程序,并部署在Cent OS中.我没有编写其代码的任何部分,但我需要优化其性能.它的当前性能对于少量用户来说是可以接受的,但是当用户数量增加时,服务器的性能会急剧下降.

是否有任何工具,技术或最佳实践来找出瓶颈？

我std::list<Info> infoList在我的应用程序中有两个线程共享.这2个线程正在访问此列表,如下所示:

主题1:使用push_back(),pop_front()或clear()在列表上(视情况而定) 线程2:使用一个iterator通过列表中的项目进行迭代,并做一些动作.

线程2正在迭代列表,如下所示:

for(std::list<Info>::iterator i = infoList.begin(); i != infoList.end(); ++i)
{
  DoAction(i);
}

代码使用GCC 4.4.2编译.

有时++ i会导致段错误并导致应用程序崩溃.该错误是在以下行的std_list.h第143行引起的:

_M_node = _M_node->_M_next;

我想这是一个赛车条件.当线程2迭代它时,列表可能已被线程1更改或甚至清除.

我使用Mutex来同步对此列表的访问,并且在我的初始测试期间一切正常.但是系统只是在压力测试下冻结,使得这个解决方案完全不可接受.此应用程序是一个实时应用程序,我需要找到一个解决方案,以便两个线程可以尽可能快地运行,而不会损害总的应用程序吞吐量.

我的问题是:线程1和线程2需要尽可能快地执行,因为这是一个实时应用程序.我该怎么做才能防止这个问题并仍然保持应用程序性能？是否有任何无锁算法可用于此类问题？

如果我Info在线程2的迭代中错过了一些新添加的对象,但是我可以做些什么来防止迭代器成为悬空指针？

谢谢

我有一个在Cent OS下运行的服务器应用程序.服务器每秒响应许多请求,但每小时左右会反复崩溃并创建一个故障转储文件.情况非常糟糕,我需要尽快找出崩溃原因.

我怀疑问题是并发问题,但我不确定.我可以访问源代码和崩溃转储文件,但我不知道如何使用崩溃转储来指出问题.

任何建议都非常感谢.

在过去的几天里,我获得了除标准以外的内存分配器的一些信息malloc().有些实现似乎比malloc()具有许多线程的应用程序好得多.例如,似乎tcmalloc并且ptmalloc具有更好的性能.

我有一个C++应用程序,在许多地方使用malloc和new运算符.我认为用ptmalloc可能会改善其性能的东西替换它们.但我想知道new运营商在Linux上运行的C++应用程序中如何运行？它是否使用标准行为malloc或其他东西？

new用代码中的旧内存分配器替换内存分配器的最佳方法是什么？有什么办法来覆盖这些行为或new和malloc或做我需要全部更换他们的电话一个接一个？

我需要使用Valgrind来检测服务器应用程序中发生的任何内存访问冲突.服务器创建许多线程.我怀疑有一种竞争条件会导致服务器每1小时左右崩溃一次.我们使用Valgrind分析其内存使用情况,但服务器进程的速度急剧下降.服务器的速度下降太多,以至于几乎无法使用,也没有可能的竞赛条件.

无论如何,与我们的应用程序并行运行Valgrind,所以我们不会失去那么多的性能？

我的C++应用程序中有一个缓冲类,如下所示:

class Buffer
{
    public:
    Buffer(size_t res): _rpos(0), _wpos(0)
    {
        _storage.reserve(res);
    }

    protected:
    size_t _rpos, _wpos;
    std::vector<uint8> _storage;
}

有时使用构造函数失败,因为它无法分配所需的内存空间.例如,一次调用构造函数res = 37导致了一个段错误,其中包含我从其核心转储获得的以下堆栈跟踪:

#0  0x00007f916a176ed5 in raise () from /lib/libc.so.6
No symbol table info available.
#1  0x00007f916a1783f3 in abort () from /lib/libc.so.6
No symbol table info available.
#2  0x00007f916a1b33a8 in ?? () from /lib/libc.so.6
No symbol table info available.
#3  0x00007f916a1b8948 in ?? () from /lib/libc.so.6
No symbol table info available.
#4  0x00007f916a1bb17c in ?? () from /lib/libc.so.6
No …