I've seen similar restrictions (2 CPU seconds or 15-20 clock seconds). In my opinion, when you are on a shared system with a typical $25-$50/month account, those limits are quite reasonable. They help ensure a minimal level of service to others on the box.

If you're doing something with a CGI that takes more than 2 CPU seconds, and have already carefully considered your algorithms and partial-result caching, you ought to consider getting onto your own box, if only out of fairness to others.

My opinion. YMMV.

So I guess with those types of web hosts running a script that might exceed those limits (eg: newsletter mailer, http link checker, etc) just isn't an option?

So I guess with those types of web hosts running a script that might exceed those limits (eg: newsletter mailer, http link checker, etc) just isn't an option?

Many ISPs distinguish (and put separate restrictions on) cron jobs. My ISP allows cron jobs for certain types of accounts, and recommends (or perhaps insists -- I'll need to check) that the jobs run nice'd. I do stuff like link checking and log analysis at nice -20 at an off-hour.

Confusingly, pair recently sent out instructions on how to install perl modules on our own accounts. Thrilled, I followed the instructions (I haven't done it myself before), only to find that some of the processes spawned by the installation got themselves killed for using too many resources.

I wrote to support asking them about this Catch-22 situation, and after a week's delay, the reply came back that if I wanted to install my own modules, I was free to compile my own version of Perl. I'm not sure how this makes any difference unless Perl Modules can be compiled into Perl .. but isn't compiling Perl also going to go over my 8M limit?

This is weird stuff.

And to echo what someone else said, my cron processes can ran no more frequently than every two hours, and they strongly recommend these processes are niced when they do run.

Next task: Do a Super Search on compiling Perl. I'll give it a shot.

--t. alex

"Of course, you realize that this means war." -- Bugs Bunny.

    *  Size of Core Files - 0 MB
    * CPU Time Used - 30 seconds
    * Data Size - 3 MB
    * File Size Created - 1 MB
    * Memory Locked - 1 MB
    * Number of Open Files - 32
    * Number of Simultaneous Processes - 8

To follow up on that, the reply from pair Networks support told me to look at this page for resource limits. The memory limit there is 8M, and that's what I was quoting.

It just plain confuses me that I can compile Perl in its entirety (just did it this morning -- only the install failed, because I can't write to /usr/local/bin) .. yet I cannot install a Perl module. It seems odd that a building a module takes more resources than Perl itself.

I guess I still have a whack of learning to do. :)

--t. alex

"Of course, you realize that this means war." -- Bugs Bunny.

First of all I hope you know that you can reinstall Perl quite easily with the customized version written to your own home directory.

Secondly at a guess your problem on install was using the CPAN module. While nice, it unfortunately routinely uses at least 16 MB on my machine. However downloading and installing modules manually should work just fine. And if all else fails, you can install them elsewhere then just copy them over. (Works for pure Perl modules quite well. Compiled ones, not always so.)

We're actually working on revising our process controls, which might include raising some of these limits (they certainly will never be lowered).

More importantly, we'll be working on a system that will allow users to "except" specific processes where necessary. Using CPAN.pm to install modules is probably a perfect example of what that feature will be for.

-Matt

We're actually working on revising our process controls, which might include raising some of these limits (they certainly will never be lowered).

Who is we? Matt, do you work at pair Networks?

--t. alex

"Of course, you realize that this means war." -- Bugs Bunny.