Date   

cloud_controller_ng performance degrades slowly over time

Matt Cholick
 

This is a pretty tricky one, as it takes a long time to manifest. After a
while without a restart, cloud_controller_ng take a long time listing org
users. For example, in an org with 350 users, before restart `cf org-users
ORG` took 1:20. After restart, the call took 0:07. We've only notice this
twice, both times after the cloud controller had been running for a couple
weeks without a restart.

Looking in New Relic, the breakdown of an individual call to
organization/guid/managers shows the majority of the call externally:

[image: Inline image 1]

Though uaa itself isn't the issue, as things are fine immediately after
restarting cloud_controller_ng (and restarting uaa has no affect).

Have other Cloud Foundry operators seen this degraded performance? Is there
other information we could provide to turn this into a workable bug report?

-Matt Cholick


Re: [ann] Subway - how to scale out any Cloud Foundry service

Dr Nic Williams
 

Subway is now also available as a bosh release; and works nicely collocated on a now-scalable bosh deployment https://blog.starkandwayne.com/2015/09/29/deploying-subway-broker-with-bosh/

On Mon, Sep 21, 2015 at 4:27 PM, Dr Nic Williams <drnic(a)starkandwayne.com>
wrote:

Quicky links:
* https://github.com/cloudfoundry-community/cf-subway
*
https://blog.starkandwayne.com/2015/09/21/how-to-scale-out-any-cloud-foundry-service/
We've been using Ferdy's Docker BOSH release since he created it, and have
published new docker images, new wrapper BOSH releases and more. But it
still doesn't scale horizontally (yes it has docker swarm support but no
that can't do persistent storage on volumes).
So we created Subway - a broker that allows you to run a fleet of
single-server service brokers such as Docker BOSH release, or
cf-redis-boshrelease.
I'll write up/create a video soon to walk-thru upgrading your existing
in-production single-server services to use Subway.
Have fun!
Nic
--
Dr Nic Williams
Stark & Wayne LLC - consultancy for Cloud Foundry users
http://drnicwilliams.com
http://starkandwayne.com
cell +1 (415) 860-2185
twitter @drnic


Using the cf-dev list for CF Abacus dev discussions

Jean-Sebastien Delfino
 

Hi all,

We've been making pretty good progress with the CF Abacus (incubating)
project recently.

So far, we've been using a mix of Gitter, Slack and Github issues for all
our detailed dev discussions but with the increased momentum in the project
I'm thinking that it's probably be a good time to start moving these dev
discussions to the cf-dev list instead.

I'm hoping that the mailing list will help organize our Abacus dev
discussions a bit better, and it should give others on the list more
opportunities to follow and participate as well.

If there's no objection I'll start posting here in a day or so.

-- Jean-Sebastien


Re: Permission denied error when unpacking droplet

Rohit Kelapure <rkelapure@...>
 

On Mon, Sep 28, 2015 at 7:03 PM, Amit Gupta <amitkgupta84(a)gmail.com> wrote:

The DEA is trying to run a script in the warden container to untar the
droplet. For some reason, the user executing the script and the file
system permissions in the container in the /home/vcap directory are not
what they're supposed to be. I believe you are deploying and running all
the Cloud Foundry components in a non-standard way. You may wish to try a
more standard deployment, and look at the differences in users and file
system permissions between the standard deployment and your deployment, and
reverse-engineer what would need to be fixed in your deployment to get
things to work. Here's a blog post, at the end it talks about how you can
get a session into a warden container (
http://andypiper.co.uk/2014/02/17/getting-inside-cloud-foundry-for-debug-and-profit/).
Alternatively you can look at the startup scripts used in the standard
deployments, e.g. (
https://github.com/cloudfoundry/cf-release/blob/master/jobs/dea_next/templates/dea_ctl.erb
).

Since you've configured all your components in a very idiosyncratic
manner, it's hard to say generally what you need to fix to get all the
permissions right.
--
Pivotal CF Architect
rkelapure(a)pivotal.io
cell: 9197242524


Re: PHP extension 'gettext' doesn't work?

Daniel Mikusa
 

It seems to be working for me [1] (at least the extension is loading, which
usually means it'll work). Can you provide some details on what you're
seeing?

- what version of PHP are you using?
- how are you enabling the extension: options.json or composer.json?
- what's the full output of `cf push`?
- what's the output of `cf logs` when you try to access a page that uses
`gettext`?

Thanks,

Dan

[1] - http://php-info.cfapps.io/info.php

On Tue, Sep 29, 2015 at 3:56 AM, Hiroaki Ukaji <dt3snow.w(a)gmail.com> wrote:

Hi.

We deployed a php application using 'gettext' extension to manage i18n
function. (*1)

We tried to activate i18n, however, it didn't work in this php application
after all.
We also tested with a simple application which contains 'gettext', but it
seemed that the extension still doesn't work.(*2)

Is there anyone who uses i18n well by using 'gettext' extension in PHP
applications?


----------
(*1)
http://blog.cloudfoundry.gr.jp/2015/09/cf100apps-067-fc2blog.html
----------
(*2)

This result should be `/home/vcap/app/htdocs/locale: Hello, world` , if
'gettext' extension works well.
----------

Thanks.

Hiroaki UKAJI




--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-PHP-extension-gettext-doesn-t-work-tp1984.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: CF API for "general statistics"?

James Bayer
 

if you're using bosh to manage cloud foundry, then the bosh cli has a
command:
bosh vms --vitals

which you can read about here [1], that does a good job of measuring infra
concerns:

- Vitals: Includes load, CPU, memory, swap, system disk, ephemeral disk,
and persistent disk usage for each VM.


[1] http://bosh.io/docs/sysadmin-commands.html#health

On Tue, Sep 29, 2015 at 2:51 AM, Rafal Radecki <radecki.rafal(a)gmail.com>
wrote:

Hi all :)

I got a task to check the possibility to fetch details such as:
- overall used and available memory/storage usage of cf platform
- list of running warden containers, approximation how many can be spawned
additionally
I looked through https://apidocs.cloudfoundry.org/218/ but did not find
anything similar to whats I am looking for.

Are there any options other than standard os level monitoring?

BR,
Rafal.


--
Thank you,

James Bayer


CF API for "general statistics"?

Rafal Radecki
 

Hi all :)

I got a task to check the possibility to fetch details such as:
- overall used and available memory/storage usage of cf platform
- list of running warden containers, approximation how many can be spawned additionally
I looked through https://apidocs.cloudfoundry.org/218/ but did not find anything similar to whats I am looking for.

Are there any options other than standard os level monitoring?

BR,
Rafal.


PHP extension 'gettext' doesn't work?

Hiroaki Ukaji <dt3snow.w@...>
 

Hi.

We deployed a php application using 'gettext' extension to manage i18n
function. (*1)

We tried to activate i18n, however, it didn't work in this php application
after all.
We also tested with a simple application which contains 'gettext', but it
seemed that the extension still doesn't work.(*2)

Is there anyone who uses i18n well by using 'gettext' extension in PHP
applications?


----------
(*1)
http://blog.cloudfoundry.gr.jp/2015/09/cf100apps-067-fc2blog.html
----------
(*2)

This result should be `/home/vcap/app/htdocs/locale: Hello, world` , if
'gettext' extension works well.
----------

Thanks.

Hiroaki UKAJI




--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-PHP-extension-gettext-doesn-t-work-tp1984.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: Permission denied error when unpacking droplet

Amit Gupta
 

The DEA is trying to run a script in the warden container to untar the droplet. For some reason, the user executing the script and the file system permissions in the container in the /home/vcap directory are not what they're supposed to be. I believe you are deploying and running all the Cloud Foundry components in a non-standard way. You may wish to try a more standard deployment, and look at the differences in users and file system permissions between the standard deployment and your deployment, and reverse-engineer what would need to be fixed in your deployment to get things to work. Here's a blog post, at the end it talks about how you can get a session into a warden container (http://andypiper.co.uk/2014/02/17/getting-inside-cloud-foundry-for-debug-and-profit/). Alternatively you can look at the startup scripts used in the standard deployments, e.g. (https://github.com/cloudfoundry/cf-release/blob/master/jobs/dea_next/templates/dea_ctl.erb).

Since you've configured all your components in a very idiosyncratic manner, it's hard to say generally what you need to fix to get all the permissions right.


Re: my app needs to get the number of instances in which its running, (in runtime my app uses this info in my program logic)

CF Runtime
 

This information is not provided to the app. You can see what data is
provided here:
http://docs.run.pivotal.io/devguide/deploy-apps/environment-variable.html#instance-vars

If you want to get this information for you app, the best way would be to
have the app call the API directly and see what the "instances" attribute
is set to.
http://apidocs.cloudfoundry.org/218/apps/retrieve_a_particular_app.html

Joseph
CF Release Integration Team

On Mon, Sep 28, 2015 at 12:14 PM, zooba Sir <myfakename90(a)gmail.com> wrote:

evaluating the performance of my app.
how my app can get the number of instances in which its running. in
runtime it needs this info in my logic.


my app needs to get the number of instances in which its running, (in runtime my app uses this info in my program logic)

Zuba Al <myfakename90@...>
 

evaluating the performance of my app.
how my app can get the number of instances in which its running. in runtime it needs this info in my logic.


Re: Instance crashing after running once. Error: "reason"=>"CRASHED", "exit_status"=>0, "exit_description"=>"app instance exited"

Zuba Al <myfakename90@...>
 

i thought exit with status 0 is error. my app is running good then.
thanks Dan.


Re: postgres out of disk space

Matthias Ender <Matthias.Ender@...>
 

thank you all!
I’m indeed running v212.
Deleting /var/vcap/store/shared/run.10.10.2.37.xip.io-cc-droplets/buildpack_cache
did the trick.


From: CF Runtime [mailto:cfruntime(a)gmail.com]
Sent: Friday, September 25, 2015 6:47 PM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] Re: Re: Re: postgres out of disk space
Importance: High

cf-release v213 fixed a bug where buildpack caches were not getting cleaned up properly. Are you running a version prior to 213?

If so, you might need to go into the `shared/run.10.10.2.37.xip.io-cc-droplets` directory and delete the `buildpack_cache` subdirectory. Deleting the contents of buildpack_cache will not cause failures in the system, the caches will simply get generated from scratch the next time apps stage.

If you upgrade to 213 or later, you can just call the api endpoint to clean out the buildpack cache. You can find the details in the v213 release notes:
https://github.com/cloudfoundry/cf-release/releases/tag/v213

Joseph & Natalie
CF Release Integration Team

On Fri, Sep 25, 2015 at 11:53 AM, Matthias Ender <Matthias.Ender(a)sas.com<mailto:Matthias.Ender(a)sas.com>> wrote:
ah, it’s not postgres:

90M postgres

it’s actually:

94G shared/run.10.10.2.37.xip.io-cc-droplets

Does it keep a copy of each artifact ever pushed?
Or is this part of the event storage, controlled by these properties:

app_events:
cutoff_age_in_days: 31
app_usage_events:
cutoff_age_in_days: 31
audit_events:
cutoff_age_in_days: 31

??


From: Aleksey Zalesov [mailto:aleksey.zalesov(a)altoros.com<mailto:aleksey.zalesov(a)altoros.com>]
Sent: Friday, September 25, 2015 12:23 PM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Subject: [cf-dev] Re: postgres out of disk space

Does your database occupy this 100 GB? Or something else like logs?

Aleksey Zalesov | CloudFoundry Engineer | Altoros
Tel: (617) 841-2121 ext. 5707<tel:%28617%29%20841-2121%20ext.%205707> | Toll free: 855-ALTOROS
Fax: (866) 201-3646<tel:%28866%29%20201-3646> | Skype: aleksey_zalesov
www.altoros.com<http://www.altoros.com/> | blog.altoros.com<http://blog.altoros.com/> | twitter.com/altoros<http://twitter.com/altoros>

On 25 Sep 2015, at 14:22, Matthias Ender <Matthias.Ender(a)sas.com<mailto:Matthias.Ender(a)sas.com>> wrote:

I have a cf-aws-tiny cf-boshrelease deployment, and it’s been running well for over 4 months.
We have about 40 apps, with a couple of dozen of cf pushes each day.
Yesterday pushing apps became spotty and then impossible, with various errors.
Turned out the 100GB disk for the postgres instance on the data note was full.
I increased the disk size and things a running again.
But – what happened there? 100G and growing seems like awfully large database for a rather modest use.
And I’m worried it’ll just happen again in a few months.

thanks,
Matthias


Permission denied error when unpacking droplet

Kyle Havlovitz (kyhavlov)
 

I'm getting the following error when pushing an app (dea logs):
{"timestamp":1443390480.7652702,"message":"\"cd /home/vcap/ && tar zxf /tmp/dea_ng/droplets/6ed0ecb3edbc2822ced1d2fb54b6d62b67a86aa8/droplet.tgz\" exited with status 2 with data {:script=>\"cd /home/vcap/ && tar zxf /tmp/dea_ng/droplets/6ed0ecb3edbc2822ced1d2fb54b6d62b67a86aa8/droplet.tgz\", :exit_status=>2, :stdout=>\"\", :stderr=>\"tar: ./logs: Cannot mkdir: Permission denied\\ntar: ./logs: Cannot mkdir: Permission denied\\ntar: ./logs/staging_task.log: Cannot open: No such file or directory\\ntar: ./tmp: Cannot mkdir: Permission denied\\ntar: ./staging_info.yml: Cannot open: Permission denied\\ntar: .: Cannot utime: Operation not permitted\\ntar: Exiting with failure status due to previous errors\\n\"}","log_level":"warn","source":"Container","data":{},"thread_id":69954816652080,"fiber_id":69954833634360,"process_id":26381,"file":"/opt/cloudfoundry/dea_next/lib/container/container.rb","lineno":80,"method":"run_script"}

I'm not sure what's causing this or the permissions needed and for what component here. Any help would be much appreciated.


Re: diego error: failed to initialize container --where to look?

Tom Sherrod <tom.sherrod@...>
 

Lesson: take error messages literally
Cell had a filled disk partition. Yes, insufficient resources.

Changed machine type, and all good.

Tom


Re: postgres out of disk space

CF Runtime
 

Droplets are important, and should not be removed. If an app is deleted,
the droplet will also be deleted. If a droplet exists, that means it is
still needed.

If the app needs to be scaled up or moved to a different runner, the
droplet is reused. In theory droplets could be recreated from the package
if it were deleted, but there is no automated behavior for this. You would
need to `restage` the app to force the system to generate a new droplet
from the existing package.

Joseph
CF Release Integration Team

On Sat, Sep 26, 2015 at 12:24 AM, Zalesov Aleksey <
aleksey.zalesov(a)altoros.com> wrote:

It will be handy to have a configuration option for CC to prune unused
droplets after 7 days of inactivity, for example.

On 26 Sep 2015, at 01:47, CF Runtime <cfruntime(a)gmail.com> wrote:

cf-release v213 fixed a bug where buildpack caches were not getting
cleaned up properly. Are you running a version prior to 213?

If so, you might need to go into the
`shared/run.10.10.2.37.xip.io-cc-droplets` directory and delete the
`buildpack_cache` subdirectory. Deleting the contents of buildpack_cache
will not cause failures in the system, the caches will simply get generated
from scratch the next time apps stage.

If you upgrade to 213 or later, you can just call the api endpoint to
clean out the buildpack cache. You can find the details in the v213 release
notes:
https://github.com/cloudfoundry/cf-release/releases/tag/v213

Joseph & Natalie
CF Release Integration Team

On Fri, Sep 25, 2015 at 11:53 AM, Matthias Ender <Matthias.Ender(a)sas.com>
wrote:

ah, it’s not postgres:



90M postgres



it’s actually:



94G shared/run.10.10.2.37.xip.io-cc-droplets



Does it keep a copy of each artifact ever pushed?

Or is this part of the event storage, controlled by these properties:



app_events:

cutoff_age_in_days: 31

app_usage_events:

cutoff_age_in_days: 31

audit_events:

cutoff_age_in_days: 31



??





*From:* Aleksey Zalesov [mailto:aleksey.zalesov(a)altoros.com]
*Sent:* Friday, September 25, 2015 12:23 PM
*To:* Discussions about Cloud Foundry projects and the system overall. <
cf-dev(a)lists.cloudfoundry.org>
*Subject:* [cf-dev] Re: postgres out of disk space



Does your database occupy this 100 GB? Or something else like logs?



Aleksey Zalesov | CloudFoundry Engineer | Altoros

Tel: (617) 841-2121 ext. 5707 | Toll free: 855-ALTOROS
Fax: (866) 201-3646 | Skype: aleksey_zalesov

www.altoros.com | blog.altoros.com | twitter.com/altoros



On 25 Sep 2015, at 14:22, Matthias Ender <Matthias.Ender(a)sas.com> wrote:



I have a cf-aws-tiny cf-boshrelease deployment, and it’s been running
well for over 4 months.

We have about 40 apps, with a couple of dozen of cf pushes each day.

Yesterday pushing apps became spotty and then impossible, with various
errors.

Turned out the 100GB disk for the postgres instance on the data note was
full.

I increased the disk size and things a running again.

But – what happened there? 100G and growing seems like awfully large
database for a rather modest use.

And I’m worried it’ll just happen again in a few months.



thanks,

Matthias




diego error: failed to initialize container --where to look?

Tom Sherrod <tom.sherrod@...>
 

After upgrade to/deploy diego in multiple environments with success, I'm a bit stumped on error for a new install.

A cf docker-push results in:
015-09-26T16:02:01.65+0000 [API/0] OUT Updated app with guid 7aa5800b-96d3-48a0-b707-1d85680e10c9 ({"state"=>"STARTED"})
2015-09-26T16:02:01.74+0000 [API/0] ERR Failed to stage application: insufficient resources

I back up a step and diego enable an app. Fails on start of app:
2015-09-26T16:14:26.38+0000 [API/0] OUT App instance exited with guid be3f6daa-96d1-41a3-8a3a-2d0ff697f8c4 payload: {"instance"=>"8d1947c6-84cb-4144-4a97-9038a7978ebf", "index"=>0, "reason"=>"CRASHED", "exit_description"=>"failed to initialize container", "crash_count"=>3, "crash_timestamp"=>1443284066323748334, "version"=>"b5a0a268-82f7-445d-937d-4349415b2a70"}

I'm betting it is one machine not being able to talk to another.
What log may provide any additional details on what's failing?

Thanks,
Tom


Re: postgres out of disk space

Aleksey Zalesov
 

It will be handy to have a configuration option for CC to prune unused droplets after 7 days of inactivity, for example.

On 26 Sep 2015, at 01:47, CF Runtime <cfruntime(a)gmail.com<mailto:cfruntime(a)gmail.com>> wrote:

cf-release v213 fixed a bug where buildpack caches were not getting cleaned up properly. Are you running a version prior to 213?

If so, you might need to go into the `shared/run.10.10.2.37.xip.io-cc-droplets` directory and delete the `buildpack_cache` subdirectory. Deleting the contents of buildpack_cache will not cause failures in the system, the caches will simply get generated from scratch the next time apps stage.

If you upgrade to 213 or later, you can just call the api endpoint to clean out the buildpack cache. You can find the details in the v213 release notes:
https://github.com/cloudfoundry/cf-release/releases/tag/v213

Joseph & Natalie
CF Release Integration Team

On Fri, Sep 25, 2015 at 11:53 AM, Matthias Ender <Matthias.Ender(a)sas.com<mailto:Matthias.Ender(a)sas.com>> wrote:
ah, it’s not postgres:

90M postgres

it’s actually:

94G shared/run.10.10.2.37.xip.io-cc-droplets

Does it keep a copy of each artifact ever pushed?
Or is this part of the event storage, controlled by these properties:

app_events:
cutoff_age_in_days: 31
app_usage_events:
cutoff_age_in_days: 31
audit_events:
cutoff_age_in_days: 31

??


From: Aleksey Zalesov [mailto:aleksey.zalesov(a)altoros.com<mailto:aleksey.zalesov(a)altoros.com>]
Sent: Friday, September 25, 2015 12:23 PM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Subject: [cf-dev] Re: postgres out of disk space

Does your database occupy this 100 GB? Or something else like logs?

Aleksey Zalesov | CloudFoundry Engineer | Altoros
Tel: (617) 841-2121 ext. 5707<tel:%28617%29%20841-2121%20ext.%205707> | Toll free: 855-ALTOROS
Fax: (866) 201-3646<tel:%28866%29%20201-3646> | Skype: aleksey_zalesov
www.altoros.com<http://www.altoros.com/> | blog.altoros.com<http://blog.altoros.com/> | twitter.com/altoros<http://twitter.com/altoros>

On 25 Sep 2015, at 14:22, Matthias Ender <Matthias.Ender(a)sas.com<mailto:Matthias.Ender(a)sas.com>> wrote:

I have a cf-aws-tiny cf-boshrelease deployment, and it’s been running well for over 4 months.
We have about 40 apps, with a couple of dozen of cf pushes each day.
Yesterday pushing apps became spotty and then impossible, with various errors.
Turned out the 100GB disk for the postgres instance on the data note was full.
I increased the disk size and things a running again.
But – what happened there? 100G and growing seems like awfully large database for a rather modest use.
And I’m worried it’ll just happen again in a few months.

thanks,
Matthias


Re: postgres out of disk space

CF Runtime
 

cf-release v213 fixed a bug where buildpack caches were not getting cleaned
up properly. Are you running a version prior to 213?

If so, you might need to go into the
`shared/run.10.10.2.37.xip.io-cc-droplets` directory and delete the
`buildpack_cache` subdirectory. Deleting the contents of buildpack_cache
will not cause failures in the system, the caches will simply get generated
from scratch the next time apps stage.

If you upgrade to 213 or later, you can just call the api endpoint to clean
out the buildpack cache. You can find the details in the v213 release notes:
https://github.com/cloudfoundry/cf-release/releases/tag/v213

Joseph & Natalie
CF Release Integration Team

On Fri, Sep 25, 2015 at 11:53 AM, Matthias Ender <Matthias.Ender(a)sas.com>
wrote:

ah, it’s not postgres:



90M postgres



it’s actually:



94G shared/run.10.10.2.37.xip.io-cc-droplets



Does it keep a copy of each artifact ever pushed?

Or is this part of the event storage, controlled by these properties:



app_events:

cutoff_age_in_days: 31

app_usage_events:

cutoff_age_in_days: 31

audit_events:

cutoff_age_in_days: 31



??





*From:* Aleksey Zalesov [mailto:aleksey.zalesov(a)altoros.com]
*Sent:* Friday, September 25, 2015 12:23 PM
*To:* Discussions about Cloud Foundry projects and the system overall. <
cf-dev(a)lists.cloudfoundry.org>
*Subject:* [cf-dev] Re: postgres out of disk space



Does your database occupy this 100 GB? Or something else like logs?



Aleksey Zalesov | CloudFoundry Engineer | Altoros

Tel: (617) 841-2121 ext. 5707 | Toll free: 855-ALTOROS
Fax: (866) 201-3646 | Skype: aleksey_zalesov

www.altoros.com | blog.altoros.com | twitter.com/altoros



On 25 Sep 2015, at 14:22, Matthias Ender <Matthias.Ender(a)sas.com> wrote:



I have a cf-aws-tiny cf-boshrelease deployment, and it’s been running well
for over 4 months.

We have about 40 apps, with a couple of dozen of cf pushes each day.

Yesterday pushing apps became spotty and then impossible, with various
errors.

Turned out the 100GB disk for the postgres instance on the data note was
full.

I increased the disk size and things a running again.

But – what happened there? 100G and growing seems like awfully large
database for a rather modest use.

And I’m worried it’ll just happen again in a few months.



thanks,

Matthias



Re: postgres out of disk space

Matthew Sykes <matthew.sykes@...>
 

Droplets and app packages should be pruned when the applications they're
associated with are deleted. Only one or two versions of the droplet are
ever held and only copy of the application bits.

There's another blob store that holds application resources for resource
match flow when uploading an app. Those resources are not pruned so you
should make sure that you disable that in your manifest if you don't want
that behavior.

The droplet blob store is clearly your issue - not events.

On Fri, Sep 25, 2015 at 2:53 PM, Matthias Ender <Matthias.Ender(a)sas.com>
wrote:

ah, it’s not postgres:



90M postgres



it’s actually:



94G shared/run.10.10.2.37.xip.io-cc-droplets



Does it keep a copy of each artifact ever pushed?

Or is this part of the event storage, controlled by these properties:



app_events:

cutoff_age_in_days: 31

app_usage_events:

cutoff_age_in_days: 31

audit_events:

cutoff_age_in_days: 31



??





*From:* Aleksey Zalesov [mailto:aleksey.zalesov(a)altoros.com]
*Sent:* Friday, September 25, 2015 12:23 PM
*To:* Discussions about Cloud Foundry projects and the system overall. <
cf-dev(a)lists.cloudfoundry.org>
*Subject:* [cf-dev] Re: postgres out of disk space



Does your database occupy this 100 GB? Or something else like logs?



Aleksey Zalesov | CloudFoundry Engineer | Altoros

Tel: (617) 841-2121 ext. 5707 | Toll free: 855-ALTOROS
Fax: (866) 201-3646 | Skype: aleksey_zalesov

www.altoros.com | blog.altoros.com | twitter.com/altoros



On 25 Sep 2015, at 14:22, Matthias Ender <Matthias.Ender(a)sas.com> wrote:



I have a cf-aws-tiny cf-boshrelease deployment, and it’s been running well
for over 4 months.

We have about 40 apps, with a couple of dozen of cf pushes each day.

Yesterday pushing apps became spotty and then impossible, with various
errors.

Turned out the 100GB disk for the postgres instance on the data note was
full.

I increased the disk size and things a running again.

But – what happened there? 100G and growing seems like awfully large
database for a rather modest use.

And I’m worried it’ll just happen again in a few months.



thanks,

Matthias




--
Matthew Sykes
matthew.sykes(a)gmail.com

7421 - 7440 of 9425