Custom Query (2152 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (1249 - 1251 of 2152)

Ticket Resolution Summary Owner Reporter
#1167 fixed Create a standard CKAN system image for Amazon EC2 (AMI) nils.toedtmann

Reported by nils.toedtmann, 3 years ago.

Description

We should create a public AMI with CKAN pre-installed and configured such that users can easily create their own EC2 machine with a running CKAN to play with.

There are three phases:

  1. [nils] Deploy an empty EC2 instance to become the CKAN image master instance
  2. Install a CKAN and give it a standard configuration.
  3. [nils] Create a AMI from the CKAN image master instance and publish it.

I am happy to do first and last. Who is installing and configuring CKAN?

Unfortunately AMIs are specific to region, architecture and storage type. We cannot maintain too many images, so a number of choices have to be made:

  • Which distribution/version? Ubuntu 10.04 LTS
  • Which architecture/instance-type? I suggest 64-bit/t1.micro
  • Which region? I suggest us-east-1 and maybe eu-west-1
  • Which storage type? EBS (way easier to make an AMI from than instance-store)
  • Install CKAN from deb packages via mercurial/virtualenv? I assume the latter because the AMI is targeted to developers?

1 2

#1345 fixed Investigate possible memory leak kindly nils.toedtmann

Reported by nils.toedtmann, 3 years ago.

Description

There is some evidence pointing to CKAN handling memory inefficiently or even leaking under certain conditions:

When we migrated ckan.net/thedatahub.org from eu7.okfn.org (32bit) to s053.okserver.org (64bit) (ticket) we experienced extraordinary memory usage peaks (ticket). Here are the observed value with Apache default settings:

  • eu7, mpm-prefork: base level ~0.6GB, peaks up to 2GB
  • s055, mpm-prefork: base level ~1GB, peaks up to 4GB
  • s055, mpm-worker: base level ~1.5GB, peaks up to 6GB

William reduced the life-time of a WSGI CKAN process from 500 requests down to 25 requests (changeset). This (together with two other tweaks) changed the situation drastically:

  • s055, mpm-event: base level ~1.4GB, no peaks

This suggests that the more requests a CKAN processes serves over time, the more memory it consumes, aka bad memory management or a leak.

To prove this theory, one could reduce the total number of WSGI CKAN processes as much as possible without killing the performance (e.g. down to processes=3), and then observing the relation between maximum-requests=25...500 and memory consumption.

On 14/09/11 17:49, David Read wrote:

Someone to do a bit of top-down memory-use profiling would be very useful. Also useful would be something in the tests that reported what test cases use lots of memory - this could be in the nose plugin.

+1

#1415 fixed Comments on current status of ckan deb packages thejimmyg nils.toedtmann

Reported by nils.toedtmann, 3 years ago.

Description

This is a scratch pad ticket with some comments on the current status of our ckan deb packages. I know that some of it is the deb packaging roadmap anyway, please forgive me if i mention them here again.

Rufus and me re-deployed some community ckan instances onto s022 (see http://trac.okfn.org/ticket/926). We followed the documentation http://docs.ckan.org/en/latest/install-from-package.html

  • Deb package version number: the version of the deb package is "python-ckan 1309471251~149be76faabc+lucid-1", and it's hard to guess from there that it contains a ckan 1.4.2a
  • When is 1.4.3/1.5.x expected as deb package?
  • There was a bug in the DB upgrade script /usr/share/pyshared/ckan/migration/versions/029_version_groups.py (line 150) which looks like it was fixed 1.4.1==>1.4.2 but was nevertheless present in this deb package.
  • The current script /usr/bin/ckan-std-install
    • does not set the Apache ServerName? according to the $INSTANCE variable
    • automatically configures a ckan extension named after $INSTANCE
    • depends on local postgres
    • could be replaced with "/usr/bin/ckan-deploy --name=ckan-std --domain=ckan-std.localhost (see next point)
  • (i think this is exactly James' plan): have more generic deployment script /usr/bin/ckan-deploy as part of python-ckan which takes arguments like
    • --domain=cc.ckan.net
    • --aliases=$list-of-domains
    • --name=cc (defaults to "domain")
    • --no-db (does not configure a DB)
    • --sql-alchemy=$DB_CONFIG_STRING (also runs "paster --plugin ckan db upgrade --config")
    • --extension $list-of-extesions
    • ...
Note: See TracQuery for help on using queries.