vicidial.org

Hello everyone.

I'm using vicidial for almost one year. I sterted from single box and now I'm using cluster installation.

I'm using Vicibox x64 (installed from original iso from kumba). VERSION: 2.6-397a BUILD: 130414-1924

Database/Web server - Core-i7, 8 GB, RAM DDR3, 2.5" notebook HDD 5400 RPM
Dialer 1 - Core-i3, 4 GB RAM DDR3, 1 TB HDD 7200 RPM
Dialer 2 - Core-i3, 4 GB RAM DDR3, 1 TB HDD 7200 RPM

I have 50 agents doing only outbound call. I'm using RATIO method (from 2.5 to 3). Recordings is forced.

Everything works fine to this Monday. I have installed new dialer: Dialer 3 - Core-i3, 4 GB RAM DDR3, 1 TB HDD 7200 RPM and now I have 70 agents.

And the problems begin:
- www freezes (on agent panel everything stops, in administration menu a cannot open any menu, i get No such page from web browser (firefox))
- while my agents are talking with customer they get another call and they are talking with 2 customers!
- and most often problem: agents are getting OUR SESSION HAS BEEN PAUSED communicate on screen. We have many DEAD calls.

Load average on database/web is: 0.06 0.04 0.05

My question are:
- are my problems related to slow hard disk on database/web? How could i check is this the problem?
- do I need to install separate web server (there will be 1 database, 1 web, 3 diallers)?
- maybe the problem lies in very big mysql database?
call_log.myd - 2.10 GB
vicidial_dial_log.myd - 1.40 GB
call_log.myi - 1.30 GB
vicidial_carier_log.myd - 1.00 GB
vicidial_log.myd - 1.00 GB

When only 50 of my agents are calling everything seems to work well. A have no freezes and double calls.
Also when 70 agents are calling everything works for 1 hour, 30 minutes, 2 hours. When the problems start a need to reboot server. Then sometimes problems start immediately or it works for 30 minutes and the problem starts.

Thanks in advance for any help!

Best regards
Zbyszek

my guess: you have installed a different version of Vicidial on the new server. It must match precisely (match the SVN revision level during install).

Solution: take it offline and reinstall it properly or "downgrade it" to the proper SVN revision level.

You are right williamconley...

My web/db server version is 1965
My two dialers are the same version.

The third dialer is version 1904 !!!

This is very strange because when we install new dialler it should match the exac version of database.
I have double checked everything and i found that on database server admin/system settings/SVN Version is 1904. This is wrong and that is why new dialer svn up to version 1904.

In Reports/Admin Utilities/Servers Versions my database is 1965.

Questions:
- how can i force my dialer to update to version 1965?
- how can i correct the version number in admin/system settings/SVN Version (it should be 1965)

Best regards
Zbyszek

phpMyAdmin is a marvelous tool for modifying database entries

Subversion is also a marvelous tool for "forcing" a revision level on a directory ...

When upgrading the vicidial repository to a specific revision level:

Code: Select all

cd /usr/src/astguiclient/trunk
svn up -r 1965

When downgrading:

Code: Select all

cd /usr/src/astguiclient/
mv trunk trunkOLD
svn co -r 1965 svn://svn.eflo.net:43690/agc_2-X/trunk

After either of these, you'll run the install script again to have it copy the necessary files to their respective locations and then reboot.

OK a followed your instructions, upgraded dialer 3, rebooted dialer 3 and now all my servers are the same version 1965.

But this did not help at all. Still have the same problems (random agent connected to dialer 1 or 2 or 3 are having problems described above).

So, I have the same quastions:
- maybe slow HDD on databaseweb server?
- to big mysql database (i dont know how big the database could be wen it start to crash)?

Best regards
Zbyszek

try shutting down that server temporarily and see if the problem "goes away". it may be a challenge with the server's identity. it may believe it's another server and behave badly as a result ... or it may be interfering with call passage in some way. easiest test I can think of before troubleshooting begins.

if that's the case, it's probably simplest to wipe it clean and reinstall it with vicibox 4.0.3 and specify the revision level during the install/cluster. Kumba has made a marvelous tool here.

I did not resolve my problems on old system.

So... I have installed a new one

Now i have 1 database, 1 web and 3 dialers. I have used Vicibox 4.0.3 x64 iso. First to go was database (installed linux, updated linux, installed vicidial, aplayed patch with crontab and downgrade mysql to 5.1 version). Next web (installed linux, updated linux, installed vicidial) and my dialers (one in time) (installed linux, updated linux, installed vicidial).

I have restored my database (only the tables that i needed) to new server.

Now with 70 agents calling everything seems to be fine

Best regards
Zbyszek

it would have been a better idea to:

complete the full install and certify box dials in autodial mode including transfers to closers on all dialers (unless you're lazy, in which case just autodial is enough to certify the box).

then backup this tested/fresh/empty database

then rename the asterisk database "newasterisk" and create a blank "asterisk" and restore the FULL prior database

then upgrade the freshly restored (but old db schema) asterisk database

then either "just go with it" (if it works) or rename this database to "oldasterisk" and rename "newasterisk" back to "asterisk".

then you can copy any "oldasterisk" table into the "asterisk" table you actually want, and the architecture has a great chance of being perfect.

if you did not upgrade those tables you moved over, you stand a pretty good chance of an "odd" bug or three in the system you just built ...

Before i restored tables that i want to new server i have upgraded old server to newest version (newest db schema, ect.) and than i have backup tables that i want. New server was the same version as old one and then i have restored my tables.

Best regards
Zbyszek