Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
From: Reddy B. <reddy.b@live.fr>
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Subject: RE: Couchdb views crashing for large documents
Thread-Topic: Couchdb views crashing for large documents
Thread-Index: AQHSRZssrtsENQ5EKkuVbOlW3w/dqKDpUEwHgAApTm2AASfAgIACDTki
Date: Sun, 27 Nov 2016 11:22:41 +0000
Message-ID: <VI1PR0502MB30699A9F0B3E60D3D345BF76F48B0@VI1PR0502MB3069.eurprd05.prod.outlook.com>
References: <VI1PR0502MB306987CB3774C6109EE9A8B5F4B70@VI1PR0502MB3069.eurprd05.prod.outlook.com>
 <VI1PR0502MB30695D1308DD03AA7C07D4B7F4890@VI1PR0502MB3069.eurprd05.prod.outlook.com>
 <VI1PR0502MB306943ECCF0F2AA1304BB47EF4890@VI1PR0502MB3069.eurprd05.prod.outlook.com>,<CADa34LAB=QrtPAsrs=HFQ9SDyt-ubA8-YBiNo7jFOov5jkPA4g@mail.gmail.com>
In-Reply-To: <CADa34LAB=QrtPAsrs=HFQ9SDyt-ubA8-YBiNo7jFOov5jkPA4g@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [HJ1bb4L74dh8ruNp9n3UDW/3n4EWkcaL]
x-incomingheadercount: 39
x-eopattributedmessage: 0
x-microsoft-exchange-diagnostics: 1;DB5EUR03HT090;7:KSyKUUevCfaNNZbn4T5JA63WF2zAnvf95xNxmBn21lJJwGszu8Ac4BIwpzTb4gt2USYpnmj1pNEUYxNx1w+1XoG6H4HRlqio8qyTBaLJ8p/sS39cbprFOYMm+sGR2F5OFIWKaPvJk8GaDFnnB08QcJGKIXXPh4kiIZWJqwl16C+xtaIzCpyfQxFNJuAb2mUIQGYQvoWQmBhpxKxayYwxYQbsZQgJLNlj/Aalw3TXaxKsqtoPVzC2BIP2gJ/DT4RglxVolqCrrZkH6quTyMlNerMSwJg9Q6JcchQz7hclSxlFajtB7krdJwZMc458D/Z9HDliS/yiD2YPgSq32yT3jXo+7K4JgslDPH2FlpESOqA=
x-forefront-antispam-report: EFV:NLI;SFV:NSPM;SFS:(10019020)(98900003);DIR:OUT;SFP:1102;SCL:1;SRVR:DB5EUR03HT090;H:VI1PR0502MB3069.eurprd05.prod.outlook.com;FPR:;SPF:None;LANG:en;
x-ms-office365-filtering-correlation-id: 5017868d-2a1a-4d8d-275e-08d416b7b3fb
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(1601124038)(1603103113)(1601125047);SRVR:DB5EUR03HT090;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(432015012)(82015046);SRVR:DB5EUR03HT090;BCL:0;PCL:0;RULEID:;SRVR:DB5EUR03HT090;
x-forefront-prvs: 0139052FDB
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_VI1PR0502MB30699A9F0B3E60D3D345BF76F48B0VI1PR0502MB3069_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2016 11:22:41.7757
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5EUR03HT090
X-OriginalArrivalTime: 27 Nov 2016 11:22:44.0291 (UTC) FILETIME=[92DA4130:01D248A0]
archived-at: Sun, 27 Nov 2016 11:22:58 -0000

--_000_VI1PR0502MB30699A9F0B3E60D3D345BF76F48B0VI1PR0502MB3069_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Many thanks for your help, unfortunately I absolutely use these fields for =
indexing.

Basically we index chapters, paragraphs etc... within "Books" documents.


Remark : This results in large arrays within the book document, and - optim=
ized - for loops within the views.

We need to stick to this design because business logic can get very complex=
, and actually even the views benefit from having access to a much required=
 context.


What I can't explain to myself is why CouchDb would use 3Gb of ram to pass =
1 document to couchjs (when I limit the number of instances of couchjs to 1=
). I sure expected this indexing scenario to be more resource intensive tha=
n usual, but it really feels like there is some sort of bug in CouchDb. It =
uses too much resources for a system reputed for operating well in low memo=
ry environment.


Our application uses a managed language, and the RAM memory overhead for in=
stanciating the exact same books I'm trying to push to couchdb is about 150=
mb per book.  How we go from that to 3Gb for a low-level database supposed =
to be optimized - and reputed to be so - is intriguing.


I'm trying to push 5, and I'm discovering that even pushing them one after =
the other turns out to not work as well as I hoped. Right now I'm getting {=
"error":"os_process_error","reason":"{exit_status,1}","ref":604603324} afte=
r 3s of indexing without clear meaning.


________________________________
De : Eli Stevens (Gmail) <wickedgrey@gmail.com>
Envoy=E9 : samedi 26 novembre 2016 04:36
=C0 : CouchDB Developers
Objet : Re: Couchdb views crashing for large documents

When bitten by similar issues, I've found that moving large data
fields to attachments can work around the size issue. As long as you
don't need that data for indexing, it works well.

Cheers,
Eli

On Fri, Nov 25, 2016 at 2:10 AM, Reddy B. <reddy.b@live.fr> wrote:
>
>
>
>  I can see that erl.exe actually crashes during the indexing, can someone=
 please tell me if the dump looks normal  ?
>
>
> http://s000.tinyupload.com/?file_id=3D39457175902042589414
TinyUpload.com - best file hosting solution, with no limits, totaly free<ht=
tp://s000.tinyupload.com/?file_id=3D39457175902042589414>
s000.tinyupload.com
TinyUpload.com - solution for tiny file hosting. No download limits, no upl=
oad limit. Totaly free.


>
>
>
> I don't know what to think about the :
>
> processes_used: 2477758424
>
> And more generally can't read between the lines yet with Erlang stuff. Th=
is is the first time CouchDb ever breaks for me, and as usual this kind of =
thing always happen at the worst time possible.
>
> These documents are basically books (storing them as one is better for de=
sign reasons). If I remove them all, and only post one book, the indexing g=
oes without any issue. I can somehow live with that for time being - thanks=
 God I own the product.... - but I cannot realistically expect that careful=
ly indexing one big document at a time can be a mid-term solution for an ap=
plication in production.
>
> I can recognize when I'm sitting on a bombshell, and I'm a bit concerned =
right now.
>
> ________________________________
> De : Reddy B. <reddy.b@live.fr>
> Envoy=E9 : mercredi 23 novembre 2016 16:06
> =C0 : Reddy B.; dev@couchdb.apache.org
> Objet : Couchdb views crashing for large documents
>
>
> Hello all !
>
> Does somebody have any idea regarding the following ?
>
> http://stackoverflow.com/questions/40752578/couchdb-views-crashing-for-la=
rge-documents
[http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-icon@2.png?v=3D=
73d79a89bded&a]<http://stackoverflow.com/questions/40752578/couchdb-views-c=
rashing-for-large-documents>

Couchdb views crashing for large documents<http://stackoverflow.com/questio=
ns/40752578/couchdb-views-crashing-for-large-documents>
stackoverflow.com
Couchdb keeps crashing whenever I try to build the index of the views of a =
design document emitting values for large documents. The total size of the =
database is 40 MB and I guess the documents are...


>
> [http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-icon@2.png?v=
=3D73d79a89bded&a]<http://stackoverflow.com/questions/40752578/couchdb-view=
s-crashing-for-large-documents>
>
> Couchdb views crashing for large documents<http://stackoverflow.com/quest=
ions/40752578/couchdb-views-crashing-for-large-documents>
[http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-icon@2.png?v=3D=
73d79a89bded&a]<http://stackoverflow.com/questions/40752578/couchdb-views-c=
rashing-for-large-documents>

Couchdb views crashing for large documents<http://stackoverflow.com/questio=
ns/40752578/couchdb-views-crashing-for-large-documents>
stackoverflow.com
Couchdb keeps crashing whenever I try to build the index of the views of a =
design document emitting values for large documents. The total size of the =
database is 40 MB and I guess the documents are...


> stackoverflow.com
> Couchdb keeps crashing whenever I try to build the index of the views of =
a design document emitting values for large documents. The total size of th=
e database is 40 MB and I guess the documents are...
>
>
>
> I've copied and pasted the question below for easy skimming :
>
> up votedown votefavorite<http://stackoverflow.com/questions/40752578/couc=
hdb-views-crashing-for-large-documents#>
>
>
> Couchdb keeps crashing whenever I try to build the index of the views of =
a design document emitting values for large documents. The total size of th=
e database is 40 MB and I guess the documents are about 5 MB each. We're ta=
lking about large JSON without any attachment.
>
> What concerns me is that I have 2.5 GB of free ram before trying to acces=
s the views but as soon as I try to access them, the CPU usage raises to 99=
% and all the free RAM gets eaten by erl.exebefore the indexing fails with =
exit code 1.
>
> Here is the log:
>
> [info] 2016-11-22T22:07:52.263000Z couchdb@localhost <0.212.0> -------- c=
ouch_proc_manager <0.15603.334> died normal
>
> [error] 2016-11-22T22:07:52.264000Z couchdb@localhost <0.15409.334> b9855=
eea74 rexi_server throw:{os_process_error,{exit_status,1}} [{couch_mrview_u=
til,get_view,4,[{file,"src/couch_mrview_util.erl"},{line,56}]},{couch_mrvie=
w,query_view,6,[{file,"src/couch_mrview.erl"},{line,244}]},{rexi_server,ini=
t_p,3,[{file,"src/rexi_server.erl"},{line,139}]}]
>
> Views skipping these documents can be accessed without issue. Which gener=
al guidelines could you provide me to help with this kind of situation? I a=
m using couchdb 2.0 on windows.
>
> Many thanks
>
>
>
>
>
>         Tried to increase the size of couchjs using various values for ./=
bin/couchjs -S MAX_RAM_TO_USE_IN_BYTES ./share/server/main.js without succe=
ss.
>
>
> I noticed that several instances of couchjs are started when I try to acc=
ess the view perhaps, is there a way to restrict the number of concurrent c=
ouchjs instances to 1 ?
>
>
>
>
>

--_000_VI1PR0502MB30699A9F0B3E60D3D345BF76F48B0VI1PR0502MB3069_--