AW: flexfax: Problems submitting very large Number of jobs sequential ly

[Christoph Stotz <pif@logo.de>]

Hi!

The answers to you questions are:

Operating System is Linux 2.0.30.
Hylafax is 4.0pl2.

The batch script looks like that:

<---cut---><---cut---><---cut---><---cut--->
faxconfig ModemClass
"exgroup:ttyD2|ttyD3|ttyD4|ttyD5|ttyD6|ttyD7|ttyX00|ttyX04"
sendfax -n -s 'a4' -t 3 -k 'now + 1 month' -m -B 14400 -b 2400 -i
'ex0001' -h exgroup@ -d '<number_to_dial1>' <filename1>.tif
sendfax -n -s 'a4' -t 3 -k 'now + 1 month' -m -B 14400 -b 2400 -i
'ex0002' -h exgroup@ -d '<number_to_dial2>' <filename2>.tif
sendfax -n -s 'a4' -t 3 -k 'now + 1 month' -m -B 14400 -b 2400 -i
'ex0003' -h exgroup@ -d '<number_to_dial3>' <filename3>.tif
sendfax -n -s 'a4' -t 3 -k 'now + 1 month' -m -B 14400 -b 2400 -i
'ex0004' -h exgroup@ -d '<number_to_dial4>' <filename4>.tif
sendfax -n -s 'a4' -t 3 -k 'now + 1 month' -m -B 14400 -b 2400 -i
'ex0005' -h exgroup@ -d '<number_to_dial5>' <filename5>.tif
(5000 lines like these following)
<---cut---><---cut---><---cut---><---cut--->

Ovviously the "<..>" strings in the real batch-file are replaced by real
data.

The Spool partition is 3.5GB. With 5000 faxes on it and (!) in the queue
it is 93% full.
My Swap-Partition is about 130MB (I know, I´m Crazy ;-)
Total (real) Memory is 64MB. During the Submitting-Phase (after 2000
faxes), cat /proc/meminfo gives:

<---cut---><---cut---><---cut---><---cut--->
        total:    used:    free:  shared: buffers:  cached:
Mem:  65560576 64159744  1400832 15183872 19591168 30703616
Swap: 133885952  8286208 125599744
MemTotal:     64024 kB
MemFree:       1368 kB
MemShared:    14828 kB
Buffers:      19132 kB
Cached:       29984 kB
SwapTotal:   130748 kB
SwapFree:    122656 kB
<---cut---><---cut---><---cut---><---cut--->


hfaxd is running as standalone and is started at bootup by
/sbin/init.d/hylafax start.

Why do you believe I´m overloading hfaxd with too many TCP-Connections ?
I believe that
the tcp-Connection is made only in the moment of submitting the job. If
it is in the
Queue, waiting for a line to become free, it should not use any
resource...

By the way: may I submit a job without using "sendfax", writing directly
the Queue-File ?

Regards,

Christoph Stotz
logo: GmbH
Superfaxing-Center ;-9

-----Ursprüngliche Nachricht-----
Von: Nico Kadel-Garcia [mailto:raoul@cirl.meei.harvard.edu]
Gesendet am: Donnerstag, 23. Juli 1998 17:44
An: Christoph Stotz
Cc: flexfax@sgi.com
Betreff: Re: flexfax: Problems submitting very large Number of jobs
sequential ly

-----BEGIN PGP SIGNED MESSAGE-----

On Thu, 23 Jul 1998, Christoph Stotz wrote:

> Hello !
> 
> We are using hylafax to send information to our customers. Normally
> about 500 faxes/day.

Cool. What operating system, Linux? And what version of HylaFAX?

> >From time to time we have to send more than 5000/day. Before sending
we
> generate all the .tif´s and
> then call a batch-programm that submit´s all the faxes sequentially.
> After some time
> submitting becomes slower and slower and CPU-Usage by faxq gets
higher:
> 
> ps -aux | grep faxq
> 
> uucp      5139 24.0  2.1  2552  1348  ?  R    Jul 21 631:16
> /usr/sbin/faxq

Umm. Could we see the batch script?

> We are using 200MHz Pentium Pro with 64MB of RAM and 12GB of Harddisk,
> so this
> should not be the problem. After 1500 jobs in the queue, the time
> between two submitted jobs
> is about 7-10 seconds.

*1500 faxes in the queue*? Yowzah! How big is your spool partition, and
could it be getting over-stuffed and slowing down?

> PS: I´m suspecting that it could by a "low memory" problem, but I do
not
> understand whay hylafax
> should use 50 MB of RAM for 1500 jobs ???

Umm. I assume you have a good chunk of swap space enabled? And are
you running hfaxd from inetd or as a stand-alone daemon?

Also, each job is (I think) opening a connection to hfaxd: you could
be vastly over-loading your available TCP connections....


			Nico Garcia
			Senior Engineer, CIRL 
			Mass. Eye and Ear Infirmary
			raoul@cirl.meei.harvard.edu

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBNbdaIT/+ItycgIJRAQExlgP/bpsIpwv6s3xfRwDXXfLj11aajIcJt3Qn
mnIBrD1YDz8G6eM5sNJ8aGAMiX98UWWzmssAYQbLXG9xUfqVU5tSs8iS2u79cdvC
pGuZlEoBb0TbIRhAiqXo9zFAcbWU9XMvxVFQmZufYafbdbE5GO1gkfqVvf+UEm3a
iDIG7oA4iAw=
=WtzM
-----END PGP SIGNATURE-----