Technically not directly covered in the Beta Freeze, but it's only running on app4 at the moment and the settings it's on now is okay for the infrequent use of casual browsing, but the Art team want to use it for the next 36 or so hours.
Can I get a +1 to bump to the resources used during the FESCo/Board votes?
Thanks
- Nigel
On Tue, 2008-09-23 at 01:08 +1200, Nigel Jones wrote:
Technically not directly covered in the Beta Freeze, but it's only running on app4 at the moment and the settings it's on now is okay for the infrequent use of casual browsing, but the Art team want to use it for the next 36 or so hours.
Can I get a +1 to bump to the resources used during the FESCo/Board votes?
Bump them to what?
-sv
On Mon, 2008-09-22 at 09:25 -0400, Seth Vidal wrote:
On Tue, 2008-09-23 at 01:08 +1200, Nigel Jones wrote:
Technically not directly covered in the Beta Freeze, but it's only running on app4 at the moment and the settings it's on now is okay for the infrequent use of casual browsing, but the Art team want to use it for the next 36 or so hours.
Can I get a +1 to bump to the resources used during the FESCo/Board votes?
Bump them to what?
Err yeah, I boo-booed and forgot to include the diff.
diff --git a/configs/web/applications/elections.conf b/configs/web/applications/elections.conf index 387f01f..4a11549 100644 --- a/configs/web/applications/elections.conf +++ b/configs/web/applications/elections.conf @@ -10,8 +10,8 @@ WSGIPythonOptimize 2
# To save resources during periods of no-elections (quite often - ~75% of the time) # We can run less threads and processes. -#WSGIDaemonProcess elections threads=2 processes=4 user=apache display-name=elections -WSGIDaemonProcess elections threads=1 processes=1 user=apache display-name=elections +WSGIDaemonProcess elections threads=2 processes=4 user=apache display-name=elections +#WSGIDaemonProcess elections threads=1 processes=1 user=apache display-name=elections
To be fair, it'd most likely be okay running at threads=2 processes=2, but I'm trying to stick with what I've used in the past with the freeze etc. -NJ
-sv
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
On Tue, 23 Sep 2008, Nigel Jones wrote:
On Mon, 2008-09-22 at 09:25 -0400, Seth Vidal wrote:
On Tue, 2008-09-23 at 01:08 +1200, Nigel Jones wrote:
Technically not directly covered in the Beta Freeze, but it's only running on app4 at the moment and the settings it's on now is okay for the infrequent use of casual browsing, but the Art team want to use it for the next 36 or so hours.
Can I get a +1 to bump to the resources used during the FESCo/Board votes?
Bump them to what?
Err yeah, I boo-booed and forgot to include the diff.
diff --git a/configs/web/applications/elections.conf b/configs/web/applications/elections.conf index 387f01f..4a11549 100644 --- a/configs/web/applications/elections.conf +++ b/configs/web/applications/elections.conf @@ -10,8 +10,8 @@ WSGIPythonOptimize 2
# To save resources during periods of no-elections (quite often - ~75% of the time) # We can run less threads and processes. -#WSGIDaemonProcess elections threads=2 processes=4 user=apache display-name=elections -WSGIDaemonProcess elections threads=1 processes=1 user=apache display-name=elections +WSGIDaemonProcess elections threads=2 processes=4 user=apache display-name=elections +#WSGIDaemonProcess elections threads=1 processes=1 user=apache display-name=elections
To be fair, it'd most likely be okay running at threads=2 processes=2, but I'm trying to stick with what I've used in the past with the freeze etc.
+1 from me.
-Mike
On Tue, Sep 23, 2008 at 01:32:23AM +1200, Nigel Jones wrote:
On Mon, 2008-09-22 at 09:25 -0400, Seth Vidal wrote:
On Tue, 2008-09-23 at 01:08 +1200, Nigel Jones wrote:
Technically not directly covered in the Beta Freeze, but it's only running on app4 at the moment and the settings it's on now is okay for the infrequent use of casual browsing, but the Art team want to use it for the next 36 or so hours.
Can I get a +1 to bump to the resources used during the FESCo/Board votes?
Bump them to what?
Err yeah, I boo-booed and forgot to include the diff.
diff --git a/configs/web/applications/elections.conf b/configs/web/applications/elections.conf index 387f01f..4a11549 100644 --- a/configs/web/applications/elections.conf +++ b/configs/web/applications/elections.conf @@ -10,8 +10,8 @@ WSGIPythonOptimize 2
# To save resources during periods of no-elections (quite often - ~75% of the time) # We can run less threads and processes. -#WSGIDaemonProcess elections threads=2 processes=4 user=apache display-name=elections -WSGIDaemonProcess elections threads=1 processes=1 user=apache display-name=elections +WSGIDaemonProcess elections threads=2 processes=4 user=apache display-name=elections +#WSGIDaemonProcess elections threads=1 processes=1 user=apache display-name=elections
To be fair, it'd most likely be okay running at threads=2 processes=2, but I'm trying to stick with what I've used in the past with the freeze etc.
+1. Looks like a harmless optimization.
We may want also want to set a 'maximum-requests' on the WSGIDaemonProcess, as to help mitigate any memory leaks within the stack (as opposed to having to use our restart-memhogs cronjob). Bodhi's is currently set to 1000, but we should probably agree on a sane number and make it consistent throughout our infrastructure. Our TurboGears SOP also needs to be updated to reflect our new WSGI deployments as well.
luke
Luke Macken wrote:
On Tue, Sep 23, 2008 at 01:32:23AM +1200, Nigel Jones wrote:
On Mon, 2008-09-22 at 09:25 -0400, Seth Vidal wrote:
On Tue, 2008-09-23 at 01:08 +1200, Nigel Jones wrote:
Technically not directly covered in the Beta Freeze, but it's only running on app4 at the moment and the settings it's on now is okay for the infrequent use of casual browsing, but the Art team want to use it for the next 36 or so hours.
Can I get a +1 to bump to the resources used during the FESCo/Board votes?
Bump them to what?
Err yeah, I boo-booed and forgot to include the diff.
diff --git a/configs/web/applications/elections.conf b/configs/web/applications/elections.conf index 387f01f..4a11549 100644 --- a/configs/web/applications/elections.conf +++ b/configs/web/applications/elections.conf @@ -10,8 +10,8 @@ WSGIPythonOptimize 2
# To save resources during periods of no-elections (quite often - ~75% of the time) # We can run less threads and processes. -#WSGIDaemonProcess elections threads=2 processes=4 user=apache display-name=elections -WSGIDaemonProcess elections threads=1 processes=1 user=apache display-name=elections +WSGIDaemonProcess elections threads=2 processes=4 user=apache display-name=elections +#WSGIDaemonProcess elections threads=1 processes=1 user=apache display-name=elections
To be fair, it'd most likely be okay running at threads=2 processes=2, but I'm trying to stick with what I've used in the past with the freeze etc.
+1. Looks like a harmless optimization.
We may want also want to set a 'maximum-requests' on the WSGIDaemonProcess, as to help mitigate any memory leaks within the stack (as opposed to having to use our restart-memhogs cronjob). Bodhi's is currently set to 1000, but we should probably agree on a sane number and make it consistent throughout our infrastructure. Our TurboGears SOP also needs to be updated to reflect our new WSGI deployments as well.
Note: restart-memhogs wasn't written with WSGI processes in mind. It will only work with supervisor controlled applications at the moment.
additional note:: in configs/web/applications/elections.conf:
WSGIScriptAlias /voting /etc/elections.wsgi/voting
Alias /voting/static /usr/share/elections/elections/static
<Directory /usr/share/elections>
This application will probably suffer from the same mod_wsgi bug we saw with fas where WSGIScriptAlias and Directory have to point at the same directory otherwise processes and threads will be ignored in WSGIDaemonProcess. If we start getting db connection issues, this is likely to be the problem that we need to correct. I'm guessing, though, that usage of the election app for the art team to vote on the theme will be low enough that we won't notice this.
-Toshio
infrastructure@lists.fedoraproject.org
-
Luke Macken -
Mike McGrath -
Nigel Jones -
Seth Vidal -
Toshio Kuratomi