Re: [PATCH] emacs: wash: make word-wrap bound message width
[notmuch-archives.git] / 53 / d90a5b352c77b1abc6cf6f8e4bc4f6c5aaca06
1 Return-Path: <amdragon@mit.edu>\r
2 X-Original-To: notmuch@notmuchmail.org\r
3 Delivered-To: notmuch@notmuchmail.org\r
4 Received: from localhost (localhost [127.0.0.1])\r
5         by olra.theworths.org (Postfix) with ESMTP id 3E170431FBD\r
6         for <notmuch@notmuchmail.org>; Thu, 24 Jul 2014 15:32:00 -0700 (PDT)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: -2.3\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5\r
12         tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled\r
13 Received: from olra.theworths.org ([127.0.0.1])\r
14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
15         with ESMTP id fIk1XAhiRXKF for <notmuch@notmuchmail.org>;\r
16         Thu, 24 Jul 2014 15:31:56 -0700 (PDT)\r
17 Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu\r
18         [18.9.25.13])\r
19         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
20         (No client certificate requested)\r
21         by olra.theworths.org (Postfix) with ESMTPS id D014F431FAF\r
22         for <notmuch@notmuchmail.org>; Thu, 24 Jul 2014 15:31:55 -0700 (PDT)\r
23 X-AuditID: 1209190d-f79c06d000002f07-fe-53d1895bfd75\r
24 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43])\r
25         (using TLS with cipher AES256-SHA (256/256 bits))\r
26         (Client did not present a certificate)\r
27         by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP\r
28         id 1F.56.12039.B5981D35; Thu, 24 Jul 2014 18:31:55 -0400 (EDT)\r
29 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])\r
30         by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s6OMVrFI029308; \r
31         Thu, 24 Jul 2014 18:31:54 -0400\r
32 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
33         (authenticated bits=0)\r
34         (User authenticated as amdragon@ATHENA.MIT.EDU)\r
35         by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6OMVpXd001562\r
36         (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);\r
37         Thu, 24 Jul 2014 18:31:53 -0400\r
38 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.80)\r
39         (envelope-from <amdragon@MIT.EDU>)\r
40         id 1XARYB-0001Q5-FW; Thu, 24 Jul 2014 18:31:50 -0400\r
41 Date: Thu, 24 Jul 2014 18:31:45 -0400\r
42 From: Austin Clements <amdragon@MIT.EDU>\r
43 To: Dmitry Bogatov <KAction@gnu.org>\r
44 Subject: Re: Notmuch new speed degradation\r
45 Message-ID: <20140724223145.GB13893@mit.edu>\r
46 References: <20140724081916.GA32474@localhost>\r
47  <20140724143214.GA13893@mit.edu>       <20140724194946.GA4724@localhost>\r
48 MIME-Version: 1.0\r
49 Content-Type: text/plain; charset=us-ascii\r
50 Content-Disposition: inline\r
51 In-Reply-To: <20140724194946.GA4724@localhost>\r
52 User-Agent: Mutt/1.5.21 (2010-09-15)\r
53 X-Brightmail-Tracker:\r
54  H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IR4hTV1o3uvBhsMLWH32L/pa8sFtdvzmR2\r
55         YPJom2bm8WzVLeYApigum5TUnMyy1CJ9uwSujLtbd7AVTBOsWLnkI3MDYxtvFyMHh4SAicTH\r
56         u6xdjJxAppjEhXvr2boYuTiEBGYzSSyc+IUdwtnIKPGhZSZU5jSTxPxj58FahASWMEps+2kA\r
57         YrMIqEq8fXubCcRmE9CQ2LZ/OSOILSKgInHmxmp2EJtZQFri2+9msBphAS2JiVdesIDYvAI6\r
58         Equ3fGKHmFkqser3dGaIuKDEyZlPWCB6tSRu/HvJBHI1yJzl/zhAwpwCehLzJnwGGykKtGrK\r
59         yW1sExiFZiHpnoWkexZC9wJG5lWMsim5Vbq5iZk5xanJusXJiXl5qUW6Rnq5mSV6qSmlmxjB\r
60         IS3Ju4Px3UGlQ4wCHIxKPLwd9ReDhVgTy4orcw8xSnIwKYnyTm8BCvEl5adUZiQWZ8QXleak\r
61         Fh9ilOBgVhLh3RgElONNSaysSi3Kh0lJc7AoifO+tbYKFhJITyxJzU5NLUgtgsnKcHAoSfB+\r
62         awdqFCxKTU+tSMvMKUFIM3FwggznARou0AEyvLggMbc4Mx0if4pRUUqc1x6kWQAkkVGaB9cL\r
63         SzmvGMWBXhHmZQRp5wGmK7juV0CDmYAGv0o4DzK4JBEhJdXAmMYldHDJUladNRG+79LcxPQq\r
64         /j+KWrKk4NRMqcm3g05xc7KdUJEQfiDznPHkt5uR11WWVtkI+tX4d9QGKF5afll+xgaP3DWJ\r
65         TqsK70YKs73sXSPc/C7y8i+BH90c8T5+/o23ljzXk5WJvnlE6+Sp+PaCZS6WS1zYJXfeuqe0\r
66         5Twro9YukexrSizFGYmGWsxFxYkAE3H5FRQDAAA=\r
67 Cc: notmuch@notmuchmail.org\r
68 X-BeenThere: notmuch@notmuchmail.org\r
69 X-Mailman-Version: 2.1.13\r
70 Precedence: list\r
71 List-Id: "Use and development of the notmuch mail system."\r
72         <notmuch.notmuchmail.org>\r
73 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
74         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
75 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
76 List-Post: <mailto:notmuch@notmuchmail.org>\r
77 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
78 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
79         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
80 X-List-Received-Date: Thu, 24 Jul 2014 22:32:00 -0000\r
81 \r
82 Quoth Dmitry Bogatov on Jul 24 at 11:49 pm:\r
83 > * Austin Clements <amdragon@MIT.EDU> [2014-07-24 10:32:14-0400]\r
84 > > Hi Dmitry.  My guess is that's you've exceeded your OS buffer cache\r
85 > > size by enough that most B-tree reads are going to disk at least once.\r
86 > > How big is your database (du -h $MAIL/.notmuch/xapian) and what does\r
87 > > free -h report on that computer?  Also, is this on an SSD or an HDD?\r
88\r
89 > 13Gb on HDD, 9G after compact. Compact did not improved indexing speed,\r
90 > unfortunately. Maybe it is possible to somehow merge databases?\r
91 \r
92 Unfortunately, there's no support for merging databases.  Other than\r
93 technical difficulties like identifying messages that should belong to\r
94 the same thread during merge, the schema wasn't designed with this in\r
95 mind and uses various features that are incompatible with merging.\r
96 \r
97 There are some known problems with Xapian slowing down as the database\r
98 gets larger, but four seconds per message still sounds extreme.\r
99 \r
100 Another thing to try is to raise Xapian's flush threshold by setting\r
101 the environment variable XAPIAN_FLUSH_THRESHOLD.  The default is\r
102 10000.  Try increasing it by, say, an order of magnitude (you can\r
103 probably go much higher than that, though you don't want to go too\r
104 high or you'll start eating in to the memory for your page cache).\r
105 \r
106 >              total       used       free     shared    buffers     cached\r
107 > Mem:          7,7G       6,5G       1,2G       240M       826M       3,6G\r
108 > -/+ buffers/cache:       2,1G       5,6G\r
109 > Swap:         1,9G        66M       1,8G\r
110 \r
111 Hmm.  Was this after the compact or after notmuch new had run for a\r
112 while?  1.2GB of free memory suggests that it's not a page cache\r
113 problem, but that would only apply if you took this snapshot after\r
114 notmuch new, not after compact.\r
115 \r
116 We should confirm that this is an IO problem.  If you run\r
117 /usr/bin/time notmuch new for a few minutes, is the %CPU significantly\r
118 below 100%?  If it's above 90%ish, then this is a CPU problem and we\r
119 might be able to track it down using CPU profiling.  If it is an IO\r
120 problem (which is almost certainly is), I'm afraid it's much harder to\r
121 track down.\r
122 \r
123 Also, what file system are you using?\r