I am running Build 2137 and it seems to get sluggish at times. I checked my server and found that it is using up 7 gigs of my available 8 gigs of memory. Is this normal? I don't have a lot of documents (52K, 10 indexes).
I am continually adding documents (10 - 20 documents at a time) from a news feeds so indexing is constantly happening.
I notice the response time in my application (on another server). It just takes about 2 - 3 seconds for a response sometimes, and I am not using any WaitForNonStaleResults anywhere.
On Monday, November 12, 2012 9:05:51 AM UTC-5, Khalid Abuhakmeh wrote:
> Hello Again,
> I am running Build 2137 and it seems to get sluggish at times. I checked > my server and found that it is using up 7 gigs of my available 8 gigs of > memory. Is this normal? I don't have a lot of documents (52K, 10 indexes).
> I am continually adding documents (10 - 20 documents at a time) from a > news feeds so indexing is constantly happening.
> I notice the response time in my application (on another server). It just > takes about 2 - 3 seconds for a response sometimes, and I am not using any > WaitForNonStaleResults anywhere.
> I am running Build 2137 and it seems to get sluggish at times. I checked
> my server and found that it is using up 7 gigs of my available 8 gigs of
> memory. Is this normal? I don't have a lot of documents (52K, 10 indexes).
> I am continually adding documents (10 - 20 documents at a time) from a
> news feeds so indexing is constantly happening.
> I notice the response time in my application (on another server). It just
> takes about 2 - 3 seconds for a response sometimes, and I am not using any
> WaitForNonStaleResults anywhere.
On Monday, November 12, 2012 9:05:51 AM UTC-5, Khalid Abuhakmeh wrote:
> Hello Again,
> I am running Build 2137 and it seems to get sluggish at times. I checked > my server and found that it is using up 7 gigs of my available 8 gigs of > memory. Is this normal? I don't have a lot of documents (52K, 10 indexes).
> I am continually adding documents (10 - 20 documents at a time) from a > news feeds so indexing is constantly happening.
> I notice the response time in my application (on another server). It just > takes about 2 - 3 seconds for a response sometimes, and I am not using any > WaitForNonStaleResults anywhere.
> I'll keep watching and see if it freaks out again.
> On Monday, November 12, 2012 9:05:51 AM UTC-5, Khalid Abuhakmeh wrote:
>> Hello Again,
>> I am running Build 2137 and it seems to get sluggish at times. I checked
>> my server and found that it is using up 7 gigs of my available 8 gigs of
>> memory. Is this normal? I don't have a lot of documents (52K, 10 indexes).
>> I am continually adding documents (10 - 20 documents at a time) from a
>> news feeds so indexing is constantly happening.
>> I notice the response time in my application (on another server). It just
>> takes about 2 - 3 seconds for a response sometimes, and I am not using any
>> WaitForNonStaleResults anywhere.
Where is the major bottle neck for RavenDB. If we had to upgrade one or two things on the server what would it be to get the most band for our buck? (Memory, Disk upgrades (SSD), or Processors)
>> I'll keep watching and see if it freaks out again.
>> On Monday, November 12, 2012 9:05:51 AM UTC-5, Khalid Abuhakmeh wrote:
>>> Hello Again,
>>> I am running Build 2137 and it seems to get sluggish at times. I >>> checked my server and found that it is using up 7 gigs of my available 8 >>> gigs of memory. Is this normal? I don't have a lot of documents (52K, 10 >>> indexes).
>>> I am continually adding documents (10 - 20 documents at a time) from a >>> news feeds so indexing is constantly happening.
>>> I notice the response time in my application (on another server). It >>> just takes about 2 - 3 seconds for a response sometimes, and I am not using >>> any WaitForNonStaleResults anywhere.
IO is probably the most important thing to watch out for.
Some things (fsync, writing indexes, etc) are pretty much IO bound.
One of the reasons that the latest version of RavenDB are significantly
faster is that we implement a pretty sophisticate pre fetching and eager
loading strategies to make sure that we don't have to wait for the IO.
On Mon, Nov 12, 2012 at 5:31 PM, Khalid Abuhakmeh <birdch...@gmail.com>wrote:
> Where is the major bottle neck for RavenDB. If we had to upgrade one or
> two things on the server what would it be to get the most band for our
> buck? (Memory, Disk upgrades (SSD), or Processors)
> Thanks,
> Khalid
> On Monday, November 12, 2012 9:45:36 AM UTC-5, Oren Eini wrote:
>> Okay, great
>> On Mon, Nov 12, 2012 at 4:44 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>> Ok I just upgraded and the pictures are before and after:
>>> I'll keep watching and see if it freaks out again.
>>> On Monday, November 12, 2012 9:05:51 AM UTC-5, Khalid Abuhakmeh wrote:
>>>> Hello Again,
>>>> I am running Build 2137 and it seems to get sluggish at times. I
>>>> checked my server and found that it is using up 7 gigs of my available 8
>>>> gigs of memory. Is this normal? I don't have a lot of documents (52K, 10
>>>> indexes).
>>>> I am continually adding documents (10 - 20 documents at a time) from a
>>>> news feeds so indexing is constantly happening.
>>>> I notice the response time in my application (on another server). It
>>>> just takes about 2 - 3 seconds for a response sometimes, and I am not using
>>>> any WaitForNonStaleResults anywhere.
On Monday, November 12, 2012 10:37:46 AM UTC-5, Oren Eini wrote:
> IO is probably the most important thing to watch out for. > Some things (fsync, writing indexes, etc) are pretty much IO bound.
> One of the reasons that the latest version of RavenDB are significantly > faster is that we implement a pretty sophisticate pre fetching and eager > loading strategies to make sure that we don't have to wait for the IO.
> On Mon, Nov 12, 2012 at 5:31 PM, Khalid Abuhakmeh <bird...@gmail.com<javascript:> > > wrote:
>> Just as a side question:
>> Where is the major bottle neck for RavenDB. If we had to upgrade one or >> two things on the server what would it be to get the most band for our >> buck? (Memory, Disk upgrades (SSD), or Processors)
>> Thanks,
>> Khalid
>> On Monday, November 12, 2012 9:45:36 AM UTC-5, Oren Eini wrote:
>>> Okay, great
>>> On Mon, Nov 12, 2012 at 4:44 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>>> Ok I just upgraded and the pictures are before and after:
>>>> I'll keep watching and see if it freaks out again.
>>>> On Monday, November 12, 2012 9:05:51 AM UTC-5, Khalid Abuhakmeh wrote:
>>>>> Hello Again,
>>>>> I am running Build 2137 and it seems to get sluggish at times. I >>>>> checked my server and found that it is using up 7 gigs of my available 8 >>>>> gigs of memory. Is this normal? I don't have a lot of documents (52K, 10 >>>>> indexes).
>>>>> I am continually adding documents (10 - 20 documents at a time) from >>>>> a news feeds so indexing is constantly happening.
>>>>> I notice the response time in my application (on another server). It >>>>> just takes about 2 - 3 seconds for a response sometimes, and I am not using >>>>> any WaitForNonStaleResults anywhere.
Yes... except that then you get into the kind of optimizations that we are
already doing, which lead us to things like multiple levels of caches,
which help dealing with it.
But yeah, fast IO, especially for seeks, helps, a lot.
On Mon, Nov 12, 2012 at 5:39 PM, Chris Marisic <ch...@marisic.com> wrote:
> And the IO is heavily seek based, such that SSD/15K rpm disks are going to
> have the largest impact, correct?
> On Monday, November 12, 2012 10:37:46 AM UTC-5, Oren Eini wrote:
>> IO is probably the most important thing to watch out for.
>> Some things (fsync, writing indexes, etc) are pretty much IO bound.
>> One of the reasons that the latest version of RavenDB are significantly
>> faster is that we implement a pretty sophisticate pre fetching and eager
>> loading strategies to make sure that we don't have to wait for the IO.
>> On Mon, Nov 12, 2012 at 5:31 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>> Just as a side question:
>>> Where is the major bottle neck for RavenDB. If we had to upgrade one or
>>> two things on the server what would it be to get the most band for our
>>> buck? (Memory, Disk upgrades (SSD), or Processors)
>>> Thanks,
>>> Khalid
>>> On Monday, November 12, 2012 9:45:36 AM UTC-5, Oren Eini wrote:
>>>> Okay, great
>>>> On Mon, Nov 12, 2012 at 4:44 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>>>> Ok I just upgraded and the pictures are before and after:
>>>>> I'll keep watching and see if it freaks out again.
>>>>> On Monday, November 12, 2012 9:05:51 AM UTC-5, Khalid Abuhakmeh wrote:
>>>>>> Hello Again,
>>>>>> I am running Build 2137 and it seems to get sluggish at times. I
>>>>>> checked my server and found that it is using up 7 gigs of my available 8
>>>>>> gigs of memory. Is this normal? I don't have a lot of documents (52K, 10
>>>>>> indexes).
>>>>>> I am continually adding documents (10 - 20 documents at a time) from
>>>>>> a news feeds so indexing is constantly happening.
>>>>>> I notice the response time in my application (on another server). It
>>>>>> just takes about 2 - 3 seconds for a response sometimes, and I am not using
>>>>>> any WaitForNonStaleResults anywhere.
On Monday, November 12, 2012 10:42:12 AM UTC-5, Oren Eini wrote:
> Yes... except that then you get into the kind of optimizations that we are > already doing, which lead us to things like multiple levels of caches, > which help dealing with it.
> But yeah, fast IO, especially for seeks, helps, a lot.
> On Mon, Nov 12, 2012 at 5:39 PM, Chris Marisic <ch...@marisic.com<javascript:> > > wrote:
>> And the IO is heavily seek based, such that SSD/15K rpm disks are going >> to have the largest impact, correct?
>> On Monday, November 12, 2012 10:37:46 AM UTC-5, Oren Eini wrote:
>>> IO is probably the most important thing to watch out for. >>> Some things (fsync, writing indexes, etc) are pretty much IO bound.
>>> One of the reasons that the latest version of RavenDB are significantly >>> faster is that we implement a pretty sophisticate pre fetching and eager >>> loading strategies to make sure that we don't have to wait for the IO.
>>> On Mon, Nov 12, 2012 at 5:31 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>>> Just as a side question:
>>>> Where is the major bottle neck for RavenDB. If we had to upgrade one or >>>> two things on the server what would it be to get the most band for our >>>> buck? (Memory, Disk upgrades (SSD), or Processors)
>>>> Thanks,
>>>> Khalid
>>>> On Monday, November 12, 2012 9:45:36 AM UTC-5, Oren Eini wrote:
>>>>> Okay, great
>>>>> On Mon, Nov 12, 2012 at 4:44 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>>>>> Ok I just upgraded and the pictures are before and after:
>>>>>> I'll keep watching and see if it freaks out again.
>>>>>> On Monday, November 12, 2012 9:05:51 AM UTC-5, Khalid Abuhakmeh >>>>>> wrote:
>>>>>>> Hello Again,
>>>>>>> I am running Build 2137 and it seems to get sluggish at times. I >>>>>>> checked my server and found that it is using up 7 gigs of my available 8 >>>>>>> gigs of memory. Is this normal? I don't have a lot of documents (52K, 10 >>>>>>> indexes).
>>>>>>> I am continually adding documents (10 - 20 documents at a time) >>>>>>> from a news feeds so indexing is constantly happening.
>>>>>>> I notice the response time in my application (on another server). It >>>>>>> just takes about 2 - 3 seconds for a response sometimes, and I am not using >>>>>>> any WaitForNonStaleResults anywhere.
> On Monday, November 12, 2012 10:42:12 AM UTC-5, Oren Eini wrote:
>> Yes... except that then you get into the kind of optimizations that we
>> are already doing, which lead us to things like multiple levels of caches,
>> which help dealing with it.
>> But yeah, fast IO, especially for seeks, helps, a lot.
>> On Mon, Nov 12, 2012 at 5:39 PM, Chris Marisic <ch...@marisic.com> wrote:
>>> And the IO is heavily seek based, such that SSD/15K rpm disks are going
>>> to have the largest impact, correct?
>>> On Monday, November 12, 2012 10:37:46 AM UTC-5, Oren Eini wrote:
>>>> IO is probably the most important thing to watch out for.
>>>> Some things (fsync, writing indexes, etc) are pretty much IO bound.
>>>> One of the reasons that the latest version of RavenDB are significantly
>>>> faster is that we implement a pretty sophisticate pre fetching and eager
>>>> loading strategies to make sure that we don't have to wait for the IO.
>>>> On Mon, Nov 12, 2012 at 5:31 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>>>> Just as a side question:
>>>>> Where is the major bottle neck for RavenDB. If we had to upgrade one
>>>>> or two things on the server what would it be to get the most band for our
>>>>> buck? (Memory, Disk upgrades (SSD), or Processors)
>>>>> Thanks,
>>>>> Khalid
>>>>> On Monday, November 12, 2012 9:45:36 AM UTC-5, Oren Eini wrote:
>>>>>> Okay, great
>>>>>> On Mon, Nov 12, 2012 at 4:44 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>>>>>> Ok I just upgraded and the pictures are before and after:
>>>>>>> I'll keep watching and see if it freaks out again.
>>>>>>> On Monday, November 12, 2012 9:05:51 AM UTC-5, Khalid Abuhakmeh
>>>>>>> wrote:
>>>>>>>> Hello Again,
>>>>>>>> I am running Build 2137 and it seems to get sluggish at times. I
>>>>>>>> checked my server and found that it is using up 7 gigs of my available 8
>>>>>>>> gigs of memory. Is this normal? I don't have a lot of documents (52K, 10
>>>>>>>> indexes).
>>>>>>>> I am continually adding documents (10 - 20 documents at a time)
>>>>>>>> from a news feeds so indexing is constantly happening.
>>>>>>>> I notice the response time in my application (on another server).
>>>>>>>> It just takes about 2 - 3 seconds for a response sometimes, and I am not
>>>>>>>> using any WaitForNonStaleResults anywhere.
>> On Monday, November 12, 2012 10:42:12 AM UTC-5, Oren Eini wrote:
>>> Yes... except that then you get into the kind of optimizations that we >>> are already doing, which lead us to things like multiple levels of caches, >>> which help dealing with it.
>>> But yeah, fast IO, especially for seeks, helps, a lot.
>>> On Mon, Nov 12, 2012 at 5:39 PM, Chris Marisic <ch...@marisic.com>wrote:
>>>> And the IO is heavily seek based, such that SSD/15K rpm disks are going >>>> to have the largest impact, correct?
>>>> On Monday, November 12, 2012 10:37:46 AM UTC-5, Oren Eini wrote:
>>>>> IO is probably the most important thing to watch out for. >>>>> Some things (fsync, writing indexes, etc) are pretty much IO bound.
>>>>> One of the reasons that the latest version of RavenDB are >>>>> significantly faster is that we implement a pretty sophisticate pre >>>>> fetching and eager loading strategies to make sure that we don't have to >>>>> wait for the IO.
>>>>> On Mon, Nov 12, 2012 at 5:31 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>>>>> Just as a side question:
>>>>>> Where is the major bottle neck for RavenDB. If we had to upgrade one >>>>>> or two things on the server what would it be to get the most band for our >>>>>> buck? (Memory, Disk upgrades (SSD), or Processors)
>>>>>> Thanks,
>>>>>> Khalid
>>>>>> On Monday, November 12, 2012 9:45:36 AM UTC-5, Oren Eini wrote:
>>>>>>> Okay, great
>>>>>>> On Mon, Nov 12, 2012 at 4:44 PM, Khalid Abuhakmeh <bird...@gmail.com >>>>>>> > wrote:
>>>>>>>> Ok I just upgraded and the pictures are before and after:
>>>>>>>> I'll keep watching and see if it freaks out again.
>>>>>>>> On Monday, November 12, 2012 9:05:51 AM UTC-5, Khalid Abuhakmeh >>>>>>>> wrote:
>>>>>>>>> Hello Again,
>>>>>>>>> I am running Build 2137 and it seems to get sluggish at times. I >>>>>>>>> checked my server and found that it is using up 7 gigs of my available 8 >>>>>>>>> gigs of memory. Is this normal? I don't have a lot of documents (52K, 10 >>>>>>>>> indexes).
>>>>>>>>> I am continually adding documents (10 - 20 documents at a time) >>>>>>>>> from a news feeds so indexing is constantly happening.
>>>>>>>>> I notice the response time in my application (on another server). >>>>>>>>> It just takes about 2 - 3 seconds for a response sometimes, and I am not >>>>>>>>> using any WaitForNonStaleResults anywhere.
>>> On Monday, November 12, 2012 10:42:12 AM UTC-5, Oren Eini wrote:
>>>> Yes... except that then you get into the kind of optimizations that we
>>>> are already doing, which lead us to things like multiple levels of caches,
>>>> which help dealing with it.
>>>> But yeah, fast IO, especially for seeks, helps, a lot.
>>>> On Mon, Nov 12, 2012 at 5:39 PM, Chris Marisic <ch...@marisic.com>wrote:
>>>>> And the IO is heavily seek based, such that SSD/15K rpm disks are
>>>>> going to have the largest impact, correct?
>>>>> On Monday, November 12, 2012 10:37:46 AM UTC-5, Oren Eini wrote:
>>>>>> IO is probably the most important thing to watch out for.
>>>>>> Some things (fsync, writing indexes, etc) are pretty much IO bound.
>>>>>> One of the reasons that the latest version of RavenDB are
>>>>>> significantly faster is that we implement a pretty sophisticate pre
>>>>>> fetching and eager loading strategies to make sure that we don't have to
>>>>>> wait for the IO.
>>>>>> On Mon, Nov 12, 2012 at 5:31 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>>>>>> Just as a side question:
>>>>>>> Where is the major bottle neck for RavenDB. If we had to upgrade one
>>>>>>> or two things on the server what would it be to get the most band for our
>>>>>>> buck? (Memory, Disk upgrades (SSD), or Processors)
>>>>>>> Thanks,
>>>>>>> Khalid
>>>>>>> On Monday, November 12, 2012 9:45:36 AM UTC-5, Oren Eini wrote:
>>>>>>>> Okay, great
>>>>>>>> On Mon, Nov 12, 2012 at 4:44 PM, Khalid Abuhakmeh <
>>>>>>>> bird...@gmail.com> wrote:
>>>>>>>>> Ok I just upgraded and the pictures are before and after:
>>>>>>>>> I'll keep watching and see if it freaks out again.
>>>>>>>>> On Monday, November 12, 2012 9:05:51 AM UTC-5, Khalid Abuhakmeh
>>>>>>>>> wrote:
>>>>>>>>>> Hello Again,
>>>>>>>>>> I am running Build 2137 and it seems to get sluggish at times. I
>>>>>>>>>> checked my server and found that it is using up 7 gigs of my available 8
>>>>>>>>>> gigs of memory. Is this normal? I don't have a lot of documents (52K, 10
>>>>>>>>>> indexes).
>>>>>>>>>> I am continually adding documents (10 - 20 documents at a time)
>>>>>>>>>> from a news feeds so indexing is constantly happening.
>>>>>>>>>> I notice the response time in my application (on another server).
>>>>>>>>>> It just takes about 2 - 3 seconds for a response sometimes, and I am not
>>>>>>>>>> using any WaitForNonStaleResults anywhere.
I can certain say that this isn't supposed to happen, so it is probably
something that we missed. Hopefully it is obvious what it will be once we
have everything at hand.
We can do a skype call tomorrow to resolve this.
On Mon, Nov 12, 2012 at 6:31 PM, Oren Eini (Ayende Rahien) <
>>>> On Monday, November 12, 2012 10:42:12 AM UTC-5, Oren Eini wrote:
>>>>> Yes... except that then you get into the kind of optimizations that we
>>>>> are already doing, which lead us to things like multiple levels of caches,
>>>>> which help dealing with it.
>>>>> But yeah, fast IO, especially for seeks, helps, a lot.
>>>>> On Mon, Nov 12, 2012 at 5:39 PM, Chris Marisic <ch...@marisic.com>wrote:
>>>>>> And the IO is heavily seek based, such that SSD/15K rpm disks are
>>>>>> going to have the largest impact, correct?
>>>>>> On Monday, November 12, 2012 10:37:46 AM UTC-5, Oren Eini wrote:
>>>>>>> IO is probably the most important thing to watch out for.
>>>>>>> Some things (fsync, writing indexes, etc) are pretty much IO bound.
>>>>>>> One of the reasons that the latest version of RavenDB are
>>>>>>> significantly faster is that we implement a pretty sophisticate pre
>>>>>>> fetching and eager loading strategies to make sure that we don't have to
>>>>>>> wait for the IO.
>>>>>>> On Mon, Nov 12, 2012 at 5:31 PM, Khalid Abuhakmeh <bird...@gmail.com
>>>>>>> > wrote:
>>>>>>>> Just as a side question:
>>>>>>>> Where is the major bottle neck for RavenDB. If we had to upgrade
>>>>>>>> one or two things on the server what would it be to get the most band for
>>>>>>>> our buck? (Memory, Disk upgrades (SSD), or Processors)
>>>>>>>> Thanks,
>>>>>>>> Khalid
>>>>>>>> On Monday, November 12, 2012 9:45:36 AM UTC-5, Oren Eini wrote:
>>>>>>>>> Okay, great
>>>>>>>>> On Mon, Nov 12, 2012 at 4:44 PM, Khalid Abuhakmeh <
>>>>>>>>> bird...@gmail.com> wrote:
>>>>>>>>>> Ok I just upgraded and the pictures are before and after:
>>>>>>>>>> I'll keep watching and see if it freaks out again.
>>>>>>>>>> On Monday, November 12, 2012 9:05:51 AM UTC-5, Khalid Abuhakmeh
>>>>>>>>>> wrote:
>>>>>>>>>>> Hello Again,
>>>>>>>>>>> I am running Build 2137 and it seems to get sluggish at times.
>>>>>>>>>>> I checked my server and found that it is using up 7 gigs of my available 8
>>>>>>>>>>> gigs of memory. Is this normal? I don't have a lot of documents (52K, 10
>>>>>>>>>>> indexes).
>>>>>>>>>>> I am continually adding documents (10 - 20 documents at a time)
>>>>>>>>>>> from a news feeds so indexing is constantly happening.
>>>>>>>>>>> I notice the response time in my application (on another
>>>>>>>>>>> server). It just takes about 2 - 3 seconds for a response sometimes, and I
>>>>>>>>>>> am not using any WaitForNonStaleResults anywhere.
On Monday, November 12, 2012 11:32:44 AM UTC-5, Oren Eini wrote:
> I can certain say that this isn't supposed to happen, so it is probably > something that we missed. Hopefully it is obvious what it will be once we > have everything at hand. > We can do a skype call tomorrow to resolve this.
> On Mon, Nov 12, 2012 at 6:31 PM, Oren Eini (Ayende Rahien) < > aye...@ayende.com <javascript:>> wrote:
>> I am not sure either. >> Can you try to run this under a memory profiler, to see what is taking so >> much memory?
>> On Mon, Nov 12, 2012 at 6:29 PM, Khalid Abuhakmeh <bird...@gmail.com<javascript:> >> > wrote:
>>> Here are the stats, not sure what I should be looking at.
>>> Not sure how you would reproduce this issue other than spinning up a new >>> environment and duplicating the database.
>>> On Monday, November 12, 2012 11:23:55 AM UTC-5, Oren Eini wrote:
>>>> Okay, can you reproduce it? >>>> What does the /stats endpoint shows?
>>>> On Mon, Nov 12, 2012 at 6:18 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>>>> The issue is back and not sure what is going on.
>>>>> On Monday, November 12, 2012 10:42:12 AM UTC-5, Oren Eini wrote:
>>>>>> Yes... except that then you get into the kind of optimizations that >>>>>> we are already doing, which lead us to things like multiple levels of >>>>>> caches, which help dealing with it.
>>>>>> But yeah, fast IO, especially for seeks, helps, a lot.
>>>>>> On Mon, Nov 12, 2012 at 5:39 PM, Chris Marisic <ch...@marisic.com>wrote:
>>>>>>> And the IO is heavily seek based, such that SSD/15K rpm disks are >>>>>>> going to have the largest impact, correct?
>>>>>>> On Monday, November 12, 2012 10:37:46 AM UTC-5, Oren Eini wrote:
>>>>>>>> IO is probably the most important thing to watch out for. >>>>>>>> Some things (fsync, writing indexes, etc) are pretty much IO bound.
>>>>>>>> One of the reasons that the latest version of RavenDB are >>>>>>>> significantly faster is that we implement a pretty sophisticate pre >>>>>>>> fetching and eager loading strategies to make sure that we don't have to >>>>>>>> wait for the IO.
>>>>>>>> On Mon, Nov 12, 2012 at 5:31 PM, Khalid Abuhakmeh < >>>>>>>> bird...@gmail.com> wrote:
>>>>>>>>> Just as a side question:
>>>>>>>>> Where is the major bottle neck for RavenDB. If we had to upgrade >>>>>>>>> one or two things on the server what would it be to get the most band for >>>>>>>>> our buck? (Memory, Disk upgrades (SSD), or Processors)
>>>>>>>>> Thanks,
>>>>>>>>> Khalid
>>>>>>>>> On Monday, November 12, 2012 9:45:36 AM UTC-5, Oren Eini wrote:
>>>>>>>>>> Okay, great
>>>>>>>>>> On Mon, Nov 12, 2012 at 4:44 PM, Khalid Abuhakmeh < >>>>>>>>>> bird...@gmail.com> wrote:
>>>>>>>>>>> Ok I just upgraded and the pictures are before and after:
>>>>>>>>>>> I'll keep watching and see if it freaks out again.
>>>>>>>>>>> On Monday, November 12, 2012 9:05:51 AM UTC-5, Khalid Abuhakmeh >>>>>>>>>>> wrote:
>>>>>>>>>>>> Hello Again,
>>>>>>>>>>>> I am running Build 2137 and it seems to get sluggish at times. >>>>>>>>>>>> I checked my server and found that it is using up 7 gigs of my available 8 >>>>>>>>>>>> gigs of memory. Is this normal? I don't have a lot of documents (52K, 10 >>>>>>>>>>>> indexes).
>>>>>>>>>>>> I am continually adding documents (10 - 20 documents at a time) >>>>>>>>>>>> from a news feeds so indexing is constantly happening.
>>>>>>>>>>>> I notice the response time in my application (on another >>>>>>>>>>>> server). It just takes about 2 - 3 seconds for a response sometimes, and I >>>>>>>>>>>> am not using any WaitForNonStaleResults anywhere.
On Monday, November 12, 2012 11:50:57 AM UTC-5, Khalid Abuhakmeh wrote:
> What memory profiler would you like?
> On Monday, November 12, 2012 11:32:44 AM UTC-5, Oren Eini wrote:
>> I can certain say that this isn't supposed to happen, so it is probably >> something that we missed. Hopefully it is obvious what it will be once we >> have everything at hand. >> We can do a skype call tomorrow to resolve this.
>> On Mon, Nov 12, 2012 at 6:31 PM, Oren Eini (Ayende Rahien) < >> aye...@ayende.com> wrote:
>>> I am not sure either. >>> Can you try to run this under a memory profiler, to see what is taking >>> so much memory?
>>> On Mon, Nov 12, 2012 at 6:29 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>>> Here are the stats, not sure what I should be looking at.
>>>> Not sure how you would reproduce this issue other than spinning up a >>>> new environment and duplicating the database.
>>>> On Monday, November 12, 2012 11:23:55 AM UTC-5, Oren Eini wrote:
>>>>> Okay, can you reproduce it? >>>>> What does the /stats endpoint shows?
>>>>> On Mon, Nov 12, 2012 at 6:18 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>>>>> The issue is back and not sure what is going on.
>>>>>> On Monday, November 12, 2012 10:42:12 AM UTC-5, Oren Eini wrote:
>>>>>>> Yes... except that then you get into the kind of optimizations that >>>>>>> we are already doing, which lead us to things like multiple levels of >>>>>>> caches, which help dealing with it.
>>>>>>> But yeah, fast IO, especially for seeks, helps, a lot.
>>>>>>> On Mon, Nov 12, 2012 at 5:39 PM, Chris Marisic <ch...@marisic.com>wrote:
>>>>>>>> And the IO is heavily seek based, such that SSD/15K rpm disks are >>>>>>>> going to have the largest impact, correct?
>>>>>>>> On Monday, November 12, 2012 10:37:46 AM UTC-5, Oren Eini wrote:
>>>>>>>>> IO is probably the most important thing to watch out for. >>>>>>>>> Some things (fsync, writing indexes, etc) are pretty much IO bound.
>>>>>>>>> One of the reasons that the latest version of RavenDB are >>>>>>>>> significantly faster is that we implement a pretty sophisticate pre >>>>>>>>> fetching and eager loading strategies to make sure that we don't have to >>>>>>>>> wait for the IO.
>>>>>>>>> On Mon, Nov 12, 2012 at 5:31 PM, Khalid Abuhakmeh < >>>>>>>>> bird...@gmail.com> wrote:
>>>>>>>>>> Just as a side question:
>>>>>>>>>> Where is the major bottle neck for RavenDB. If we had to upgrade >>>>>>>>>> one or two things on the server what would it be to get the most band for >>>>>>>>>> our buck? (Memory, Disk upgrades (SSD), or Processors)
>>>>>>>>>> Thanks,
>>>>>>>>>> Khalid
>>>>>>>>>> On Monday, November 12, 2012 9:45:36 AM UTC-5, Oren Eini wrote:
>>>>>>>>>>> Okay, great
>>>>>>>>>>> On Mon, Nov 12, 2012 at 4:44 PM, Khalid Abuhakmeh < >>>>>>>>>>> bird...@gmail.com> wrote:
>>>>>>>>>>>> Ok I just upgraded and the pictures are before and after:
>>>>>>>>>>>> I'll keep watching and see if it freaks out again.
>>>>>>>>>>>> On Monday, November 12, 2012 9:05:51 AM UTC-5, Khalid >>>>>>>>>>>> Abuhakmeh wrote:
>>>>>>>>>>>>> Hello Again,
>>>>>>>>>>>>> I am running Build 2137 and it seems to get sluggish at >>>>>>>>>>>>> times. I checked my server and found that it is using up 7 gigs of my >>>>>>>>>>>>> available 8 gigs of memory. Is this normal? I don't have a lot of documents >>>>>>>>>>>>> (52K, 10 indexes).
>>>>>>>>>>>>> I am continually adding documents (10 - 20 documents at a >>>>>>>>>>>>> time) from a news feeds so indexing is constantly happening.
>>>>>>>>>>>>> I notice the response time in my application (on another >>>>>>>>>>>>> server). It just takes about 2 - 3 seconds for a response sometimes, and I >>>>>>>>>>>>> am not using any WaitForNonStaleResults anywhere.
> On Monday, November 12, 2012 11:32:44 AM UTC-5, Oren Eini wrote:
>> I can certain say that this isn't supposed to happen, so it is probably
>> something that we missed. Hopefully it is obvious what it will be once we
>> have everything at hand.
>> We can do a skype call tomorrow to resolve this.
>> On Mon, Nov 12, 2012 at 6:31 PM, Oren Eini (Ayende Rahien) <
>> aye...@ayende.com> wrote:
>>> I am not sure either.
>>> Can you try to run this under a memory profiler, to see what is taking
>>> so much memory?
>>> On Mon, Nov 12, 2012 at 6:29 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>>> Here are the stats, not sure what I should be looking at.
>>>> Not sure how you would reproduce this issue other than spinning up a
>>>> new environment and duplicating the database.
>>>> On Monday, November 12, 2012 11:23:55 AM UTC-5, Oren Eini wrote:
>>>>> Okay, can you reproduce it?
>>>>> What does the /stats endpoint shows?
>>>>> On Mon, Nov 12, 2012 at 6:18 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>>>>> The issue is back and not sure what is going on.
>>>>>> On Monday, November 12, 2012 10:42:12 AM UTC-5, Oren Eini wrote:
>>>>>>> Yes... except that then you get into the kind of optimizations that
>>>>>>> we are already doing, which lead us to things like multiple levels of
>>>>>>> caches, which help dealing with it.
>>>>>>> But yeah, fast IO, especially for seeks, helps, a lot.
>>>>>>> On Mon, Nov 12, 2012 at 5:39 PM, Chris Marisic <ch...@marisic.com>wrote:
>>>>>>>> And the IO is heavily seek based, such that SSD/15K rpm disks are
>>>>>>>> going to have the largest impact, correct?
>>>>>>>> On Monday, November 12, 2012 10:37:46 AM UTC-5, Oren Eini wrote:
>>>>>>>>> IO is probably the most important thing to watch out for.
>>>>>>>>> Some things (fsync, writing indexes, etc) are pretty much IO bound.
>>>>>>>>> One of the reasons that the latest version of RavenDB are
>>>>>>>>> significantly faster is that we implement a pretty sophisticate pre
>>>>>>>>> fetching and eager loading strategies to make sure that we don't have to
>>>>>>>>> wait for the IO.
>>>>>>>>> On Mon, Nov 12, 2012 at 5:31 PM, Khalid Abuhakmeh <
>>>>>>>>> bird...@gmail.com> wrote:
>>>>>>>>>> Just as a side question:
>>>>>>>>>> Where is the major bottle neck for RavenDB. If we had to upgrade
>>>>>>>>>> one or two things on the server what would it be to get the most band for
>>>>>>>>>> our buck? (Memory, Disk upgrades (SSD), or Processors)
>>>>>>>>>> Thanks,
>>>>>>>>>> Khalid
>>>>>>>>>> On Monday, November 12, 2012 9:45:36 AM UTC-5, Oren Eini wrote:
>>>>>>>>>>> Okay, great
>>>>>>>>>>> On Mon, Nov 12, 2012 at 4:44 PM, Khalid Abuhakmeh <
>>>>>>>>>>> bird...@gmail.com> wrote:
>>>>>>>>>>>> Ok I just upgraded and the pictures are before and after:
>>>>>>>>>>>> I'll keep watching and see if it freaks out again.
>>>>>>>>>>>> On Monday, November 12, 2012 9:05:51 AM UTC-5, Khalid
>>>>>>>>>>>> Abuhakmeh wrote:
>>>>>>>>>>>>> Hello Again,
>>>>>>>>>>>>> I am running Build 2137 and it seems to get sluggish at
>>>>>>>>>>>>> times. I checked my server and found that it is using up 7 gigs of my
>>>>>>>>>>>>> available 8 gigs of memory. Is this normal? I don't have a lot of documents
>>>>>>>>>>>>> (52K, 10 indexes).
>>>>>>>>>>>>> I am continually adding documents (10 - 20 documents at a
>>>>>>>>>>>>> time) from a news feeds so indexing is constantly happening.
>>>>>>>>>>>>> I notice the response time in my application (on another
>>>>>>>>>>>>> server). It just takes about 2 - 3 seconds for a response sometimes, and I
>>>>>>>>>>>>> am not using any WaitForNonStaleResults anywhere.
DotTrace it is. Seeing it slowly climb from 2 gigs up to 4 gigs as I install the profiler. Looks like a memory leak from the task manager. I'll take some snapshots and see what happens.
On Monday, November 12, 2012 11:56:01 AM UTC-5, Oren Eini wrote:
> JetBrains dotTrace is the one I routinely use,
> On Mon, Nov 12, 2012 at 6:50 PM, Khalid Abuhakmeh <bird...@gmail.com<javascript:> > > wrote:
>> What memory profiler would you like?
>> On Monday, November 12, 2012 11:32:44 AM UTC-5, Oren Eini wrote:
>>> I can certain say that this isn't supposed to happen, so it is probably >>> something that we missed. Hopefully it is obvious what it will be once we >>> have everything at hand. >>> We can do a skype call tomorrow to resolve this.
>>> On Mon, Nov 12, 2012 at 6:31 PM, Oren Eini (Ayende Rahien) < >>> aye...@ayende.com> wrote:
>>>> I am not sure either. >>>> Can you try to run this under a memory profiler, to see what is taking >>>> so much memory?
>>>> On Mon, Nov 12, 2012 at 6:29 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>>>> Here are the stats, not sure what I should be looking at.
>>>>> Not sure how you would reproduce this issue other than spinning up a >>>>> new environment and duplicating the database.
>>>>> On Monday, November 12, 2012 11:23:55 AM UTC-5, Oren Eini wrote:
>>>>>> Okay, can you reproduce it? >>>>>> What does the /stats endpoint shows?
>>>>>> On Mon, Nov 12, 2012 at 6:18 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>>>>>> The issue is back and not sure what is going on.
>>>>>>> On Monday, November 12, 2012 10:42:12 AM UTC-5, Oren Eini wrote:
>>>>>>>> Yes... except that then you get into the kind of optimizations that >>>>>>>> we are already doing, which lead us to things like multiple levels of >>>>>>>> caches, which help dealing with it.
>>>>>>>> But yeah, fast IO, especially for seeks, helps, a lot.
>>>>>>>> On Mon, Nov 12, 2012 at 5:39 PM, Chris Marisic <ch...@marisic.com>wrote:
>>>>>>>>> And the IO is heavily seek based, such that SSD/15K rpm disks are >>>>>>>>> going to have the largest impact, correct?
>>>>>>>>> On Monday, November 12, 2012 10:37:46 AM UTC-5, Oren Eini wrote:
>>>>>>>>>> IO is probably the most important thing to watch out for. >>>>>>>>>> Some things (fsync, writing indexes, etc) are pretty much IO >>>>>>>>>> bound.
>>>>>>>>>> One of the reasons that the latest version of RavenDB are >>>>>>>>>> significantly faster is that we implement a pretty sophisticate pre >>>>>>>>>> fetching and eager loading strategies to make sure that we don't have to >>>>>>>>>> wait for the IO.
>>>>>>>>>> On Mon, Nov 12, 2012 at 5:31 PM, Khalid Abuhakmeh < >>>>>>>>>> bird...@gmail.com> wrote:
>>>>>>>>>>> Just as a side question:
>>>>>>>>>>> Where is the major bottle neck for RavenDB. If we had to upgrade >>>>>>>>>>> one or two things on the server what would it be to get the most band for >>>>>>>>>>> our buck? (Memory, Disk upgrades (SSD), or Processors)
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Khalid
>>>>>>>>>>> On Monday, November 12, 2012 9:45:36 AM UTC-5, Oren Eini wrote:
>>>>>>>>>>>> Okay, great
>>>>>>>>>>>> On Mon, Nov 12, 2012 at 4:44 PM, Khalid Abuhakmeh < >>>>>>>>>>>> bird...@gmail.com> wrote:
>>>>>>>>>>>>> Ok I just upgraded and the pictures are before and after:
>>>>>>>>>>>>> I'll keep watching and see if it freaks out again.
>>>>>>>>>>>>> On Monday, November 12, 2012 9:05:51 AM UTC-5, Khalid >>>>>>>>>>>>> Abuhakmeh wrote:
>>>>>>>>>>>>>> Hello Again,
>>>>>>>>>>>>>> I am running Build 2137 and it seems to get sluggish at >>>>>>>>>>>>>> times. I checked my server and found that it is using up 7 gigs of my >>>>>>>>>>>>>> available 8 gigs of memory. Is this normal? I don't have a lot of documents >>>>>>>>>>>>>> (52K, 10 indexes).
>>>>>>>>>>>>>> I am continually adding documents (10 - 20 documents at a >>>>>>>>>>>>>> time) from a news feeds so indexing is constantly happening.
>>>>>>>>>>>>>> I notice the response time in my application (on another >>>>>>>>>>>>>> server). It just takes about 2 - 3 seconds for a response sometimes, and I >>>>>>>>>>>>>> am not using any WaitForNonStaleResults anywhere.
I had to use DotTrace 4 to take snapshots due to my environment. You can download the files below. I didn't see anything odd in terms of files escalating out of control.
On Monday, November 12, 2012 11:58:46 AM UTC-5, Khalid Abuhakmeh wrote:
> DotTrace it is. Seeing it slowly climb from 2 gigs up to 4 gigs as I > install the profiler. Looks like a memory leak from the task manager. I'll > take some snapshots and see what happens.
> On Monday, November 12, 2012 11:56:01 AM UTC-5, Oren Eini wrote:
>> JetBrains dotTrace is the one I routinely use,
>> On Mon, Nov 12, 2012 at 6:50 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>> What memory profiler would you like?
>>> On Monday, November 12, 2012 11:32:44 AM UTC-5, Oren Eini wrote:
>>>> I can certain say that this isn't supposed to happen, so it is probably >>>> something that we missed. Hopefully it is obvious what it will be once we >>>> have everything at hand. >>>> We can do a skype call tomorrow to resolve this.
>>>> On Mon, Nov 12, 2012 at 6:31 PM, Oren Eini (Ayende Rahien) < >>>> aye...@ayende.com> wrote:
>>>>> I am not sure either. >>>>> Can you try to run this under a memory profiler, to see what is taking >>>>> so much memory?
>>>>> On Mon, Nov 12, 2012 at 6:29 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>>>>> Here are the stats, not sure what I should be looking at.
>>>>>> Not sure how you would reproduce this issue other than spinning up a >>>>>> new environment and duplicating the database.
>>>>>> On Monday, November 12, 2012 11:23:55 AM UTC-5, Oren Eini wrote:
>>>>>>> Okay, can you reproduce it? >>>>>>> What does the /stats endpoint shows?
>>>>>>> On Mon, Nov 12, 2012 at 6:18 PM, Khalid Abuhakmeh <bird...@gmail.com >>>>>>> > wrote:
>>>>>>>> The issue is back and not sure what is going on.
>>>>>>>> On Monday, November 12, 2012 10:42:12 AM UTC-5, Oren Eini wrote:
>>>>>>>>> Yes... except that then you get into the kind of optimizations >>>>>>>>> that we are already doing, which lead us to things like multiple levels of >>>>>>>>> caches, which help dealing with it.
>>>>>>>>> But yeah, fast IO, especially for seeks, helps, a lot.
>>>>>>>>> On Mon, Nov 12, 2012 at 5:39 PM, Chris Marisic <ch...@marisic.com>wrote:
>>>>>>>>>> And the IO is heavily seek based, such that SSD/15K rpm disks are >>>>>>>>>> going to have the largest impact, correct?
>>>>>>>>>> On Monday, November 12, 2012 10:37:46 AM UTC-5, Oren Eini wrote:
>>>>>>>>>>> IO is probably the most important thing to watch out for. >>>>>>>>>>> Some things (fsync, writing indexes, etc) are pretty much IO >>>>>>>>>>> bound.
>>>>>>>>>>> One of the reasons that the latest version of RavenDB are >>>>>>>>>>> significantly faster is that we implement a pretty sophisticate pre >>>>>>>>>>> fetching and eager loading strategies to make sure that we don't have to >>>>>>>>>>> wait for the IO.
>>>>>>>>>>> On Mon, Nov 12, 2012 at 5:31 PM, Khalid Abuhakmeh < >>>>>>>>>>> bird...@gmail.com> wrote:
>>>>>>>>>>>> Just as a side question:
>>>>>>>>>>>> Where is the major bottle neck for RavenDB. If we had to >>>>>>>>>>>> upgrade one or two things on the server what would it be to get the most >>>>>>>>>>>> band for our buck? (Memory, Disk upgrades (SSD), or Processors)
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Khalid
>>>>>>>>>>>> On Monday, November 12, 2012 9:45:36 AM UTC-5, Oren Eini wrote:
>>>>>>>>>>>>> Okay, great
>>>>>>>>>>>>> On Mon, Nov 12, 2012 at 4:44 PM, Khalid Abuhakmeh < >>>>>>>>>>>>> bird...@gmail.com> wrote:
>>>>>>>>>>>>>> Ok I just upgraded and the pictures are before and after:
>>>>>>>>>>>>>> I'll keep watching and see if it freaks out again.
>>>>>>>>>>>>>> On Monday, November 12, 2012 9:05:51 AM UTC-5, Khalid >>>>>>>>>>>>>> Abuhakmeh wrote:
>>>>>>>>>>>>>>> Hello Again,
>>>>>>>>>>>>>>> I am running Build 2137 and it seems to get sluggish at >>>>>>>>>>>>>>> times. I checked my server and found that it is using up 7 gigs of my >>>>>>>>>>>>>>> available 8 gigs of memory. Is this normal? I don't have a lot of documents >>>>>>>>>>>>>>> (52K, 10 indexes).
>>>>>>>>>>>>>>> I am continually adding documents (10 - 20 documents at a >>>>>>>>>>>>>>> time) from a news feeds so indexing is constantly happening.
>>>>>>>>>>>>>>> I notice the response time in my application (on another >>>>>>>>>>>>>>> server). It just takes about 2 - 3 seconds for a response sometimes, and I >>>>>>>>>>>>>>> am not using any WaitForNonStaleResults anywhere.
I seem to be getting some kind of memory leak too, I haven't had chance to get any hard evidence with tracing and such, but in more recent builds my server always seems to max out the memory (32gb) and become unstable.
> I seem to be getting some kind of memory leak too, I haven't had chance to
> get any hard evidence with tracing and such, but in more recent builds my
> server always seems to max out the memory (32gb) and become unstable.
> I had to use DotTrace 4 to take snapshots due to my environment. You can
> download the files below. I didn't see anything odd in terms of files
> escalating out of control.
> On Monday, November 12, 2012 11:58:46 AM UTC-5, Khalid Abuhakmeh wrote:
>> DotTrace it is. Seeing it slowly climb from 2 gigs up to 4 gigs as I
>> install the profiler. Looks like a memory leak from the task manager. I'll
>> take some snapshots and see what happens.
>> On Monday, November 12, 2012 11:56:01 AM UTC-5, Oren Eini wrote:
>>> JetBrains dotTrace is the one I routinely use,
>>> On Mon, Nov 12, 2012 at 6:50 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>>> What memory profiler would you like?
>>>> On Monday, November 12, 2012 11:32:44 AM UTC-5, Oren Eini wrote:
>>>>> I can certain say that this isn't supposed to happen, so it is
>>>>> probably something that we missed. Hopefully it is obvious what it will be
>>>>> once we have everything at hand.
>>>>> We can do a skype call tomorrow to resolve this.
>>>>> On Mon, Nov 12, 2012 at 6:31 PM, Oren Eini (Ayende Rahien) <
>>>>> aye...@ayende.com> wrote:
>>>>>> I am not sure either.
>>>>>> Can you try to run this under a memory profiler, to see what is
>>>>>> taking so much memory?
>>>>>> On Mon, Nov 12, 2012 at 6:29 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>>>>>> Here are the stats, not sure what I should be looking at.
>>>>>>> Not sure how you would reproduce this issue other than spinning up a
>>>>>>> new environment and duplicating the database.
>>>>>>> On Monday, November 12, 2012 11:23:55 AM UTC-5, Oren Eini wrote:
>>>>>>>> Okay, can you reproduce it?
>>>>>>>> What does the /stats endpoint shows?
>>>>>>>> On Mon, Nov 12, 2012 at 6:18 PM, Khalid Abuhakmeh <
>>>>>>>> bird...@gmail.com> wrote:
>>>>>>>>> The issue is back and not sure what is going on.
>>>>>>>>> On Monday, November 12, 2012 10:42:12 AM UTC-5, Oren Eini wrote:
>>>>>>>>>> Yes... except that then you get into the kind of optimizations
>>>>>>>>>> that we are already doing, which lead us to things like multiple levels of
>>>>>>>>>> caches, which help dealing with it.
>>>>>>>>>> But yeah, fast IO, especially for seeks, helps, a lot.
>>>>>>>>>> On Mon, Nov 12, 2012 at 5:39 PM, Chris Marisic <ch...@marisic.com
>>>>>>>>>> > wrote:
>>>>>>>>>>> And the IO is heavily seek based, such that SSD/15K rpm disks
>>>>>>>>>>> are going to have the largest impact, correct?
>>>>>>>>>>> On Monday, November 12, 2012 10:37:46 AM UTC-5, Oren Eini wrote:
>>>>>>>>>>>> IO is probably the most important thing to watch out for.
>>>>>>>>>>>> Some things (fsync, writing indexes, etc) are pretty much IO
>>>>>>>>>>>> bound.
>>>>>>>>>>>> One of the reasons that the latest version of RavenDB are
>>>>>>>>>>>> significantly faster is that we implement a pretty sophisticate pre
>>>>>>>>>>>> fetching and eager loading strategies to make sure that we don't have to
>>>>>>>>>>>> wait for the IO.
>>>>>>>>>>>> On Mon, Nov 12, 2012 at 5:31 PM, Khalid Abuhakmeh <
>>>>>>>>>>>> bird...@gmail.com> wrote:
>>>>>>>>>>>>> Just as a side question:
>>>>>>>>>>>>> Where is the major bottle neck for RavenDB. If we had to
>>>>>>>>>>>>> upgrade one or two things on the server what would it be to get the most
>>>>>>>>>>>>> band for our buck? (Memory, Disk upgrades (SSD), or Processors)
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Khalid
>>>>>>>>>>>>> On Monday, November 12, 2012 9:45:36 AM UTC-5, Oren Eini
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> Okay, great
>>>>>>>>>>>>>> On Mon, Nov 12, 2012 at 4:44 PM, Khalid Abuhakmeh <
>>>>>>>>>>>>>> bird...@gmail.com> wrote:
>>>>>>>>>>>>>>> Ok I just upgraded and the pictures are before and after:
>>>>>>>>>>>>>>> I'll keep watching and see if it freaks out again.
>>>>>>>>>>>>>>> On Monday, November 12, 2012 9:05:51 AM UTC-5, Khalid
>>>>>>>>>>>>>>> Abuhakmeh wrote:
>>>>>>>>>>>>>>>> Hello Again,
>>>>>>>>>>>>>>>> I am running Build 2137 and it seems to get sluggish at
>>>>>>>>>>>>>>>> times. I checked my server and found that it is using up 7 gigs of my
>>>>>>>>>>>>>>>> available 8 gigs of memory. Is this normal? I don't have a lot of documents
>>>>>>>>>>>>>>>> (52K, 10 indexes).
>>>>>>>>>>>>>>>> I am continually adding documents (10 - 20 documents at a
>>>>>>>>>>>>>>>> time) from a news feeds so indexing is constantly happening.
>>>>>>>>>>>>>>>> I notice the response time in my application (on another
>>>>>>>>>>>>>>>> server). It just takes about 2 - 3 seconds for a response sometimes, and I
>>>>>>>>>>>>>>>> am not using any WaitForNonStaleResults anywhere.
On Tuesday, November 13, 2012 7:07:47 AM UTC-5, Oren Eini wrote:
> I tried to open them with dot Trace memory, but it doesn't know how to > deal with those files.
> On Mon, Nov 12, 2012 at 9:21 PM, Khalid Abuhakmeh <bird...@gmail.com<javascript:> > > wrote:
>> I had to use DotTrace 4 to take snapshots due to my environment. You can >> download the files below. I didn't see anything odd in terms of files >> escalating out of control.
>> On Monday, November 12, 2012 11:58:46 AM UTC-5, Khalid Abuhakmeh wrote:
>>> DotTrace it is. Seeing it slowly climb from 2 gigs up to 4 gigs as I >>> install the profiler. Looks like a memory leak from the task manager. I'll >>> take some snapshots and see what happens.
>>> On Monday, November 12, 2012 11:56:01 AM UTC-5, Oren Eini wrote:
>>>> JetBrains dotTrace is the one I routinely use,
>>>> On Mon, Nov 12, 2012 at 6:50 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>>>> What memory profiler would you like?
>>>>> On Monday, November 12, 2012 11:32:44 AM UTC-5, Oren Eini wrote:
>>>>>> I can certain say that this isn't supposed to happen, so it is >>>>>> probably something that we missed. Hopefully it is obvious what it will be >>>>>> once we have everything at hand. >>>>>> We can do a skype call tomorrow to resolve this.
>>>>>> On Mon, Nov 12, 2012 at 6:31 PM, Oren Eini (Ayende Rahien) < >>>>>> aye...@ayende.com> wrote:
>>>>>>> I am not sure either. >>>>>>> Can you try to run this under a memory profiler, to see what is >>>>>>> taking so much memory?
>>>>>>> On Mon, Nov 12, 2012 at 6:29 PM, Khalid Abuhakmeh <bird...@gmail.com >>>>>>> > wrote:
>>>>>>>> Here are the stats, not sure what I should be looking at.
>>>>>>>> Not sure how you would reproduce this issue other than spinning up >>>>>>>> a new environment and duplicating the database.
>>>>>>>> On Monday, November 12, 2012 11:23:55 AM UTC-5, Oren Eini wrote:
>>>>>>>>> Okay, can you reproduce it? >>>>>>>>> What does the /stats endpoint shows?
>>>>>>>>> On Mon, Nov 12, 2012 at 6:18 PM, Khalid Abuhakmeh < >>>>>>>>> bird...@gmail.com> wrote:
>>>>>>>>>> The issue is back and not sure what is going on.
>>>>>>>>>> On Monday, November 12, 2012 10:42:12 AM UTC-5, Oren Eini wrote:
>>>>>>>>>>> Yes... except that then you get into the kind of optimizations >>>>>>>>>>> that we are already doing, which lead us to things like multiple levels of >>>>>>>>>>> caches, which help dealing with it.
>>>>>>>>>>> But yeah, fast IO, especially for seeks, helps, a lot.
>>>>>>>>>>> On Mon, Nov 12, 2012 at 5:39 PM, Chris Marisic < >>>>>>>>>>> ch...@marisic.com> wrote:
>>>>>>>>>>>> And the IO is heavily seek based, such that SSD/15K rpm disks >>>>>>>>>>>> are going to have the largest impact, correct?
>>>>>>>>>>>> On Monday, November 12, 2012 10:37:46 AM UTC-5, Oren Eini >>>>>>>>>>>> wrote:
>>>>>>>>>>>>> IO is probably the most important thing to watch out for. >>>>>>>>>>>>> Some things (fsync, writing indexes, etc) are pretty much IO >>>>>>>>>>>>> bound.
>>>>>>>>>>>>> One of the reasons that the latest version of RavenDB are >>>>>>>>>>>>> significantly faster is that we implement a pretty sophisticate pre >>>>>>>>>>>>> fetching and eager loading strategies to make sure that we don't have to >>>>>>>>>>>>> wait for the IO.
>>>>>>>>>>>>> On Mon, Nov 12, 2012 at 5:31 PM, Khalid Abuhakmeh < >>>>>>>>>>>>> bird...@gmail.com> wrote:
>>>>>>>>>>>>>> Just as a side question:
>>>>>>>>>>>>>> Where is the major bottle neck for RavenDB. If we had to >>>>>>>>>>>>>> upgrade one or two things on the server what would it be to get the most >>>>>>>>>>>>>> band for our buck? (Memory, Disk upgrades (SSD), or Processors)
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Khalid
>>>>>>>>>>>>>> On Monday, November 12, 2012 9:45:36 AM UTC-5, Oren Eini >>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> Okay, great
>>>>>>>>>>>>>>> On Mon, Nov 12, 2012 at 4:44 PM, Khalid Abuhakmeh < >>>>>>>>>>>>>>> bird...@gmail.com> wrote:
>>>>>>>>>>>>>>>> Ok I just upgraded and the pictures are before and after:
>>>>>>>>>>>>>>>> I'll keep watching and see if it freaks out again.
>>>>>>>>>>>>>>>> On Monday, November 12, 2012 9:05:51 AM UTC-5, Khalid >>>>>>>>>>>>>>>> Abuhakmeh wrote:
>>>>>>>>>>>>>>>>> Hello Again,
>>>>>>>>>>>>>>>>> I am running Build 2137 and it seems to get sluggish at >>>>>>>>>>>>>>>>> times. I checked my server and found that it is using up 7 gigs of my >>>>>>>>>>>>>>>>> available 8 gigs of memory. Is this normal? I don't have a lot of documents >>>>>>>>>>>>>>>>> (52K, 10 indexes).
>>>>>>>>>>>>>>>>> I am continually adding documents (10 - 20 documents at a >>>>>>>>>>>>>>>>> time) from a news feeds so indexing is constantly happening.
>>>>>>>>>>>>>>>>> I notice the response time in my application (on another >>>>>>>>>>>>>>>>> server). It just takes about 2 - 3 seconds for a response sometimes, and I >>>>>>>>>>>>>>>>> am not using any WaitForNonStaleResults anywhere.
Since you are having same issues as me I'll just add to this thread -
In profiling we see tons of *System.LocalDataStoreElement *in memory. It keeps growing. Looking into it I stumbled upon this - http://support.microsoft.com/kb/2540745
Oren, do you have that hotfix on your test boxes by any chance?
