CPU: 1,650 MHz RAM: 2,048 MB Storage: 10 GB SSD OS: Apache/2.2.9 (Debian) mod_perl/2.0.4 Perl/v5.10.0. 5 agents. Check Ticket::SearchIndexModule setting. You are using "Kernel::System::Ticket::ArticleSearchIndex::RuntimeDB", that's fine for 44050 articles in your system. Check Ticket::IndexModule setting. You are using "Kernel::System::Ticket::IndexAccelerator::RuntimeDB", that's fine for 12824 tickets in your system. 2011/10/7 Arnold Ligtvoet

We running OTRS on a dedicated server with a lot of RAM, CUP and disk space. We have high wolume of new tickets and around 15 POP 3 accounts. The OTRS system running very slow now. Anyone that could help us with any tips or point us to any good forum article?

Perhaps some more information would help. How much ram, CPU, operating system, number of agents and tickets. It could perhaps allow people to give better advice.

Did you already optimize db settings?

Arnold ** --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

root@*****:~# vmstat 10 10 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 0 461752 0 0 0 0 0 3 0 0 0 0 100 0 0 0 0 461492 0 0 0 0 0 0 0 487 0 0 100 0 0 0 0 461492 0 0 0 0 0 0 0 485 0 0 100 0 0 0 0 461492 0 0 0 0 0 0 0 490 0 0 100 0 0 0 0 461492 0 0 0 0 0 0 0 539 0 0 100 0 0 0 0 461492 0 0 0 0 0 0 0 360 0 0 100 0 0 0 0 461492 0 0 0 0 0 0 0 498 0 0 100 0 0 0 0 460172 0 0 0 0 0 121 0 1098 0 0 100 0 0 0 0 460120 0 0 0 0 0 0 0 495 0 0 100 0 0 0 0 460120 0 0 0 0 0 0 0 467 0 0 100 0 root@*****:~# We are using SSD HDD, so we dont create a SWAP area.... 2011/10/8 Ugo Bellavance

Le 2011-10-07 18:43, Jean BROW a écrit :

CPU: 1,650 MHz

...

RAM: 2,048 MB Storage: 10 GB SSD OS: Apache/2.2.9 (Debian) mod_perl/2.0.4 Perl/v5.10.0.

5 agents.

Please send the output of vmstat 10 10

------------------------------**------------------------------**--------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/**pipermail/otrshttp://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/**listinfo/otrshttp://lists.otrs.org/cgi-bin/listinfo/otrs

Le 2011-10-08 07:03, Jean BROW a écrit :

root@*****:~# vmstat 10 10 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 0 461752 0 0 0 0 0 3 0 0 0 0 100 0 0 0 0 461492 0 0 0 0 0 0 0 487 0 0 100 0 0 0 0 461492 0 0 0 0 0 0 0 485 0 0 100 0 0 0 0 461492 0 0 0 0 0 0 0 490 0 0 100 0 0 0 0 461492 0 0 0 0 0 0 0 539 0 0 100 0 0 0 0 461492 0 0 0 0 0 0 0 360 0 0 100 0 0 0 0 461492 0 0 0 0 0 0 0 498 0 0 100 0 0 0 0 460172 0 0 0 0 0 121 0 1098 0 0 100 0 0 0 0 460120 0 0 0 0 0 0 0 495 0 0 100 0 0 0 0 460120 0 0 0 0 0 0 0 467 0 0 100 0 root@*****:~#

We are using SSD HDD, so we dont create a SWAP area....

Hum. Your system reports itself as being idle... Do you see anything wierd in top output?

On 2011-10-13 08:50, Jean BROW wrote:

SWAP is not going to help us I think.. As we using SSD HDD, who is better..

I think your server is probably oversized for the load it has to deal with, so I'd check on the network side. Any congestion? Collisions? Something is weird with the vmstat output though... how come you've got 0 for buffers and cache? Please send the output of top -b -n 1

DNS and name resolution on the host is working fine ?

I had a similar issue also related to DNS, but not that obvious. Some months ago, I reconfigured the whole internal network at one site to use IPv6, including DNS. All internal servers have an IPv6 record (AAAA) in DNS as well as an IPv4 record (A). Unfortunately, I forgot to tell the OTRS web server instance to talk IPv6 as well (it doesn't by default), so clients connecting to the server got an IPv6 address for the host name, tried that, ran into a timeout and tried the IPv4 record next, which of course worked. The result was exactly what the TO is experiencing: Extremely slow operation of OTRS on an apparently mostly idle server. If this could be the reason, the TO should try the following commands (provided he's on an Unixoid OS, such as Linux or Mac OS X - don't know about the related commands in Windows): $ dig otrs.server.name AAAA $ telnet -6 otrs.server.name 80 If the first commmand returns an IPv6 address and the second fails with a timeout, the reason for the slowness is probably incorrect IPv6 rollout. Best regards, Peter.