what is the iops allocated to your aws instance? On Wed, 21 Sep 2022, 17:36 Derek C, <[email protected]> wrote:
> Hi all, > > I'm trying to identify a SOLR query performance issue (or rather how to > size [AWS EC2] hardware to support many users). > > Right now I'm testing on a single SOLR node (with distrib=false to keep the > query to the one node). > > I'm using Apache JMeter to test (with many different queries in a CSV) and > I'm using prometheus-exporter / prometheus / Grafana to view the status of > the SOLR node/replica). I'm also looking at top for CPU usage and iotop > for disk IO on the VM/instance. > > Right now the VM/instance is a x2gd.xlarge which is Graviton based with 4 > [v]CPUs and 64Gbytes of memory (32Gbytes to SOLR and 32Gbytes to O/S). > > My collection is 20Gbytes in size with about 2.5 million documents. > > Interestingly when I run a test I don't see any disk I/O reads at all - so > I think [debian] linux has cached the index in RAM (great I think). > > What I don't understand is that if I run a lot of parallel/rolling queries > (probably 1,500) with JMeter what I see [in top] is the CPU *not* hitting > 400% (4 cores) and, from time to time, it's at 0% which is really weird - I > would expect the CPU to be the the bottleneck (and the thing to be scaled > up for more performance). Meanwhile queries are taking over 10 seconds to > respond. > > I'm not really sure where to look (in the Grafana SOLR dashboard?) to look > further and try to find out more. > > If anyone has any suggestions it's be great > > thanks, > > Derek > > -- > Derek Conniffe > Harvey Software Systems Ltd T/A HSSL > Skype: dconnrt > Email: [email protected] > > > *Disclaimer:* This email and any files transmitted with it are confidential > and intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please delete it > (if you are not the intended recipient you are notified that disclosing, > copying, distributing or taking any action in reliance on the contents of > this information is strictly prohibited). > *Warning*: Although HSSL have taken reasonable precautions to ensure no > viruses are present in this email, HSSL cannot accept responsibility for > any loss or damage arising from the use of this email or attachments. > P For the Environment, please only print this email if necessary. >
