- #Archipel ejabberd openssl install
- #Archipel ejabberd openssl upgrade
- #Archipel ejabberd openssl simulator
#Archipel ejabberd openssl install
Yum install mysql mysql-server phpMyAdmin httpd Gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6 Name=Extra Packages for Enterprise Linux 6 - $basearch The machine is a T5120 with 16GB of ram and the machine and a 64 core processor.使用PureFTPd和MySQL虚拟主机(包括配额和带宽管理)在CentOS 6.2上 The memory/cpu usages of the other processes are negligible. Prstat shows memory usage around 900 MB and CPU usage from 0.5% to 1.0%. Specifically 9,227 is the number I show logged in in this last test before I start getting hit with time outs. It looks like I'm hitting a wall just over 9000 users. I have the following values set in ejabberdctl: Which I spent some time trying to solve but eventually gave up so I went back to the original R13B01 and 2.1.2 setup (I think I said 2.1.1 in my original message, but I meant 2.1.2, sorry about that).Īnyway, not worrying about why I had to disable SMP for no reason, since I've disabled it the crashes/core dumps have stopped but under load (~30000 simultaneous users) many of my simulated clients are getting time out errors when trying to sign it. In ejabberd 2.1.3 I compiled and installed from source in Debian Sid 32bits, with the Erlang packaged in Debian, with Pidgin (home) and Tkabber (work) connected to my 'badlop' account, when I execute "ejabberdctl stop", there isn't any crash, just this is logged in ejabberd.log and ejabberd stops:
#Archipel ejabberd openssl simulator
Is this expected behavior or a bug in ejabberd? So it's possible something did indeed cause the simulator to crash/stop while clients were disconnected which caused the core and not the core causing the clients to disconnect. It appears that killing the simulator with a connected client causes it to core with the same backtrace I reported.
It appears that I can recreate the core pretty easily, all I have to do is connect a client with Pidgin, then run. Still, nothing looks obvious from the change log between l/m what would resolve this issue Any other advice you have you would be helpful! Thanks!ĮDIT: The OpenSSL version is 0.9.8l not 0.9.8m, my mistake.
#Archipel ejabberd openssl upgrade
I'm willing to upgrade the Erlang and Ejabberd versions to the latest if you think it'll help, but it's not a trivial task, so I'm wondering if it'll be worth it or not. In the Erlang logs, but I'm not sure if that applies. Version that did not cope with large file descriptors.
OTP-8261 Fixed emulator crash caused by crypto using an old openssl I took a quick look at change logs for the newest version of Erlang and Ejabberd but didn't see anything particularly referencing this expect: I'm running ejabberd 2.1.1 and Erlang R13B01 and OpenSSL 0.9.8m (pretty sure it's version m) on a Solaris 10 installation. Has anyone else run into an issue like this? I've run fairly high load though it before and have not observed a problem. Looks like it might have broken somewhere in an OpenSSL call. Previous frame identical to this frame (corrupt stack?) I ran it though gdb and got a backtrace producing this: I was running some load (maybe four to five hundred transactions/second) through my ejabberd installation when I got a core dump from the Erlang virtual machine.
0 kommentar(er)
