# Virtual memory exhausted **URL:** \ **Category:** Linux\ **Created:** [September 19, 2020, 11:36pm UTC](https://travis-ci.community/t/virtual-memory-exhausted/9950 "2020-09-19T23:36:26Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![eldiener](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/eldiener/32/5209_2.png) [@eldiener](https://travis-ci.community/u/eldiener)\ **Post date:** [September 19, 2020, 11:36pm UTC](https://travis-ci.community/t/virtual-memory-exhausted/9950/1 "2020-09-19T23:36:26Z")
Testing out some Boost preprocessor library changes, for which I am the maintainer, with g++8 using Travis CI in the Ubuntu xenial distribution I get an error saying: virtual memory exhausted: Cannot allocate memory Is this coming from the OS or g++ ? Testing this out on my own system in Ubuntu there is no problem. How much virtual memory do I get with Travis CI ? Can I change my testing environment to give me more virtual memory ? It is really hard to believe that that the code, which exercises the gcc preprocessor, is actually running out of virtual memory. The URL is [https://travis-ci.org/github/boostorg/preprocessor/jobs/728647110](https://travis-ci.org/github/boostorg/preprocessor/jobs/728647110). ---
**Author:** ![Montana](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/montana/32/9566_2.png) [@Montana](https://travis-ci.community/u/Montana)\ **Post date:** [September 29, 2020, 5:30am UTC](https://travis-ci.community/t/virtual-memory-exhausted/9950/2 "2020-09-29T05:30:55Z")
Hello @eldiener, Looked over your `.travis.yml` file, have you tried adding: ```auto script: - make -j 1 test ``` See if that makes any difference at all? ---
**Author:** ![native-api](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/native-api/32/430_2.png) [@native-api](https://travis-ci.community/u/native-api)\ **Post date:** [September 29, 2020, 3:16pm UTC](https://travis-ci.community/t/virtual-memory-exhausted/9950/3 "2020-09-29T15:16:06Z")
> [@Compiling the project takes too long for a single job, Travis is timing out on me](https://travis-ci.community/t/compiling-the-project-takes-too-long-for-a-single-job-travis-is-timing-out-on-me/9981/3): > > As a side note, you should use -j\ for CPU-bound tasks like compilation. The common theory that it’s optimal to pass \ is not confirmed by experiment: > [@Python 3.7 Xenial build started to fail with “failed to map segment from shared object”](https://travis-ci.community/t/python-3-7-xenial-build-started-to-fail-with-failed-to-map-segment-from-shared-object/4341/5): > > Looking around the Net, “failed to map segment from shared object” is usually accompanied by an additional message specifying the reason. Since in this case, it isn’t and due to below, this looks like an out of memory condition. Use make -j$(nproc) instead of make -j. ---
**Author:** ![eldiener](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/eldiener/32/5209_2.png) [@eldiener](https://travis-ci.community/u/eldiener)\ **Post date:** [September 29, 2020, 3:58pm UTC](https://travis-ci.community/t/virtual-memory-exhausted/9950/4 "2020-09-29T15:58:29Z")
Is the advice setting `-j 1`, or setting `-j` to the number of CPUs ( how do I know that number ? ) , or setting `-j$(nproc)` where the nproc variable may be the number of CPUs for all I know? So what should I set `-j` to in order to possibly avoid the out of memory conditions? I agree that setting `-j` to an arbitrary number like `3` is wrong. ---
**Author:** ![native-api](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/native-api/32/430_2.png) [@native-api](https://travis-ci.community/u/native-api)\ **Post date:** [September 29, 2020, 4:26pm UTC](https://travis-ci.community/t/virtual-memory-exhausted/9950/5 "2020-09-29T16:26:57Z")
The advice is: 1. In Travis’ case, setting `-j` to anything more than 2 ([all Travis VMs are 2-core](https://docs.travis-ci.com/user/reference/overview/#virtualisation-environment-vs-operating-system)) has no positive effect in any case. 2. Set it to 1 to see if reducing the number of jobs is sufficient or you will have to [resort to something else](https://github.com/LORD-MicroStrain/MSCL/issues/76#issuecomment-470911504). If it works, try 2.