The document discusses using MongoDB as both a primary data store and queueing system for Server Density. It describes how Server Density implemented queuing functionality in MongoDB using the findAndModify command to atomically retrieve and update documents. It also provides an overview of monitoring considerations for MongoDB in production, including keeping indexes and frequently accessed data in memory, watching for disk I/O spikes or slow queries that may indicate insufficient memory, and using db.serverStatus() to monitor connection usage and check for limits.
Building a queueing system in MongoDB and monitoring your cluster. Presentation by David Mytton at MongoSF May 2011 and MongoDB London User Group July 2011.
Presentation by David Mytton about monitoring MongoDB at the MongoSV conference 3rd Dec 2010.
A full blog series covering everything in this presentation is at http://blog.boxedice.com/mongodb-monitoring/
Presentation by David Mytton about monitoring MongoDB at the MongoUK conference 21st Mar 2011.
A full blog series covering everything in this presentation is at http://blog.boxedice.com/mongodb-monitoring/
Ensuring High Availability for Real-time Analytics featuring Boxed Ice / Serv...MongoDB
This will cover what to consider for high write throughput performance from hardware configuration through to the use of replica sets, multi-data centre deployments, monitoring and sharding to ensure your database is fast and stays online.
Новые возможности полнотекстового поиска в PostgreSQL / Олег Бартунов (Postgr...Ontico
Я расскажу про новые возможности полнотекстового поиска, которые вошли в последний релиз PostgreSQL - поддержку фразового поиска и набор функций для манипулирования полнотекстовым типом данных (tsvector). Помимо этого, мы улучшили поддержку морфологических словарей, что привело к значительному увеличению числа поддерживаемых языков, оптимизировали работу со словарями, разработали новый индексный метод доступа RUM, который значительно ускорил выполнение ряда запросов с полнотекстовыми операторами.
Building a queueing system in MongoDB and monitoring your cluster. Presentation by David Mytton at MongoSF May 2011 and MongoDB London User Group July 2011.
Presentation by David Mytton about monitoring MongoDB at the MongoSV conference 3rd Dec 2010.
A full blog series covering everything in this presentation is at http://blog.boxedice.com/mongodb-monitoring/
Presentation by David Mytton about monitoring MongoDB at the MongoUK conference 21st Mar 2011.
A full blog series covering everything in this presentation is at http://blog.boxedice.com/mongodb-monitoring/
Ensuring High Availability for Real-time Analytics featuring Boxed Ice / Serv...MongoDB
This will cover what to consider for high write throughput performance from hardware configuration through to the use of replica sets, multi-data centre deployments, monitoring and sharding to ensure your database is fast and stays online.
Новые возможности полнотекстового поиска в PostgreSQL / Олег Бартунов (Postgr...Ontico
Я расскажу про новые возможности полнотекстового поиска, которые вошли в последний релиз PostgreSQL - поддержку фразового поиска и набор функций для манипулирования полнотекстовым типом данных (tsvector). Помимо этого, мы улучшили поддержку морфологических словарей, что привело к значительному увеличению числа поддерживаемых языков, оптимизировали работу со словарями, разработали новый индексный метод доступа RUM, который значительно ускорил выполнение ряда запросов с полнотекстовыми операторами.
The latest version of my PostgreSQL introduction for IL-TechTalks, a free service to introduce the Israeli hi-tech community to new and interesting technologies. In this talk, I describe the history and licensing of PostgreSQL, its built-in capabilities, and some of the new things that were added in the 9.1 and 9.2 releases which make it an attractive option for many applications.
This tutorial will guide you through the many considerations when deploying a sharded cluster. We will cover the services that make up a sharded cluster, configuration recommendations for these services, shard key selection, use cases, and how data is managed within a sharded cluster. Maintaining a sharded cluster also has its challenges. We will review these challenges and how you can prevent them with proper design or ways to resolve them if they exist today. There will be lab sessions at the end of some chapters so please have your laptops with you.
ToroDB: scaling PostgreSQL like MongoDB / Álvaro Hernández Tortosa (8Kdata)Ontico
NoSQL databases have emerged as a response to some perceived problems in the RDBMSs: agile/dynamic schemas; and transparent, horizontal scaling of the database. The former has been promptly targeted with the introduction of unstructured data types, but scaling a relational databases is still a very hard problem.
As a consequence, all NoSQL databases have been built from scratch: their storage engines, replication techniques, journaling, ACID support (if any). They haven't leveraged the previously existing state-of-the-art of RDBMSs, effectively re-inventing the wheel. Isn't this sub-optimal? Wouldn't it be possible to construct a NoSQL database by layering it on top of a relational database?
Enter ToroDB. ToroDB is an open source project that behaves as a NoSQL database but runs on top of PostgreSQL, one of the most respected and reliable relational databases. ToroDB offers a document (JSON-like) interface, and implements the MongoDB wire protocol, hence being compatible with existing MongoDB drivers and applications. Rather than using PostgreSQL's jsonb data type, ToroDB explored an innovative approach by transforming JSON documents to a fully relational representation, in an automated way. This brings to the table many advantages like lower disk footprint and automatic data-partitioning, leading to significantly faster queries.As ToroDB speaks the MongoDB protocol, it also implements MongoDB replication and sharding techniques, enabling it to scale and offer HA like Mongo. Being based on PostgreSQL, ToroDB is effectively scaling PostgreSQL much in the same way MongoDB scales.
The latest version of my PostgreSQL introduction for IL-TechTalks, a free service to introduce the Israeli hi-tech community to new and interesting technologies. In this talk, I describe the history and licensing of PostgreSQL, its built-in capabilities, and some of the new things that were added in the 9.1 and 9.2 releases which make it an attractive option for many applications.
This tutorial will guide you through the many considerations when deploying a sharded cluster. We will cover the services that make up a sharded cluster, configuration recommendations for these services, shard key selection, use cases, and how data is managed within a sharded cluster. Maintaining a sharded cluster also has its challenges. We will review these challenges and how you can prevent them with proper design or ways to resolve them if they exist today. There will be lab sessions at the end of some chapters so please have your laptops with you.
ToroDB: scaling PostgreSQL like MongoDB / Álvaro Hernández Tortosa (8Kdata)Ontico
NoSQL databases have emerged as a response to some perceived problems in the RDBMSs: agile/dynamic schemas; and transparent, horizontal scaling of the database. The former has been promptly targeted with the introduction of unstructured data types, but scaling a relational databases is still a very hard problem.
As a consequence, all NoSQL databases have been built from scratch: their storage engines, replication techniques, journaling, ACID support (if any). They haven't leveraged the previously existing state-of-the-art of RDBMSs, effectively re-inventing the wheel. Isn't this sub-optimal? Wouldn't it be possible to construct a NoSQL database by layering it on top of a relational database?
Enter ToroDB. ToroDB is an open source project that behaves as a NoSQL database but runs on top of PostgreSQL, one of the most respected and reliable relational databases. ToroDB offers a document (JSON-like) interface, and implements the MongoDB wire protocol, hence being compatible with existing MongoDB drivers and applications. Rather than using PostgreSQL's jsonb data type, ToroDB explored an innovative approach by transforming JSON documents to a fully relational representation, in an automated way. This brings to the table many advantages like lower disk footprint and automatic data-partitioning, leading to significantly faster queries.As ToroDB speaks the MongoDB protocol, it also implements MongoDB replication and sharding techniques, enabling it to scale and offer HA like Mongo. Being based on PostgreSQL, ToroDB is effectively scaling PostgreSQL much in the same way MongoDB scales.
Redis Use Patterns (DevconTLV June 2014)Itamar Haber
An introduction to Redis for the SQL practitioner, covering data types and common use cases.
The video of this session can be found at: https://www.youtube.com/watch?v=8Unaug_vmFI
The world of Microservices is a little different to standard service oriented architectures. They play to an opinionated score of decentralisation, isolation and automation. Stream processing comes from a different angle though. One where analytic function is melded to a firehose of in-flight events. Yet business applications increasingly need to be data intensive, nimble and fast to market. This isn’t as easy as it sounds.
This talk will look at the implications of mixing toolsets from the stream processing world into realtime business applications. How to effectively handle infinite streams, how to leverage a high throughput, persistent Log and deploy dynamic, fault tolerant, streaming services. By mixing these disparate domains we’ll see how we can build application architectures that can withstand the full force and immediacy of the data generation.
MongoDB for Time Series Data Part 2: Analyzing Time Series Data Using the Agg...MongoDB
The United States will be deploying 16,000 traffic speed monitoring sensors - 1 on every mile of US interstate in urban centers. These sensors update the speed, weather, and pavement conditions once per minute. MongoDB will collect and aggregate live sensor data feeds from roadways around the country, support real-time queries from cars on traffic conditions on their route as well as be the platform for real-time dashboards displaying traffic conditions and more complex analytical queries used to identify traffic trends. In this session, we’ll implement a few different data aggregation techniques to query and dashboard the metrics gathered from the US interstate.
Inilah pitch deck dari raksasa media digital, Buzzfeed. Bagi kamu yang memiliki model bisnis yang serupa dengan BuzzFeed, mungkin kamu dapat terinspirasi dari pitch deck ini.
More startup pitch deck examples here: https://attach.io/startup-pitch-decks/
AirBnb's original pitch deck from 2008. They closed a $600k seed round with this deck.
This was our final Series A deck. Read more about raising the round in this blog post:
https://medium.com/@DanielleMorrill/welcome-brad-feld-to-the-mattermark-team-announcing-our-6-5m-series-a-dd9532fc1b39
The investor presentation we used to raise 2 million dollarsMikael Cho
The investor presentation we used to raise 2 million dollars for ooomf.com (now pickcrew.com)
View the online version here: https://pickcrew.com/investors/
MongoDB 3.0 comes with a set of innovations regarding storage engine, operational facilities and improvements has well of security enhancements. This presentations describes these improvements and new features ready to be tested.
https://www.mongodb.com/lp/white-paper/mongodb-3.0
Benchmarking, Load Testing, and Preventing Terrible DisastersMongoDB
"Have you ever crossed your fingers before performing an upgrade or switching storage engines, because you weren't quite sure what would happen? Have you ever been bitten by a slight change in behavior that turned out to be unexpectedly significant for your workload? At Parse we have developed a workflow that lets us repeatedly capture and replay real production workloads offline. This has allowed us to confidently perform upgrades across a large fleet with a minimum amount of canarying, and has helped us load test a variety of storage engines with real workloads so we can compare and understand the performance tradeoffs.
In this talk we will cover best practices for upgrades and migrations, and we will walk through how to use our open-sourced tooling to demonstrate how you can do the same. We will also share some fun war stories about various disasters found and averted *before* putting them into production thanks to offline benchmarking."
DevOps for ETL processing at scale with MongoDB, Solr, AWS and ChefGaurav "GP" Pal
Large scale data processing for Extract Transform and Loading (ETL) jobs is a very common practice. The stackArmor DevOps team developed a Chef based automation solution to automate the AWS environment provisioning, code deployment and data ingestion processing to ingest and process over 2 TB of Data.
This presentation covers the technologies used, the planning phase, AWS instance selection and optimizing the ETL processing for not only performance but also cost.
The target was to process 500 million rows within 72 hours with a processing rate of 5 million transactions per hour.
The presentation also provides pitfalls and automation optimizations performed to accomplish the targeted processing rates.
The presentation was delivered at the DevOpsDC Meetup on May 17, 2016
This talk is about the ways to improve the performance of individual applications, to optimize code and architecture. It also provides a brief overview of Java tools.
This presentation was held by Oleksandr Bodnar (Senior Software Java Developer, Consultant, GlobalLogic) at GlobalLogic MykolaivJava TechTalk #2 on September 27, 2018.
Silicon Valley Code Camp 2014 - Advanced MongoDBDaniel Coupal
MongoDB presentation from Silicon Valley Code Camp 2014.
Walkthrough developing, deploying and operating a MongoDB application, avoiding the most common pitfalls.
Silicon Valley Code Camp 2015 - Advanced MongoDB - The SequelDaniel Coupal
MongoDB presentation from Silicon Valley Code Camp 2015.
Walkthrough developing, deploying and operating a MongoDB application, avoiding the most common pitfalls.
MongoDB Versatility: Scaling the MapMyFitness PlatformMongoDB
Chris Merz, Manager of Operations, MapMyFitness
The MMF user base more than doubled in 2011, beginning an era of rapid data growth. With Big Data come Big Data Headaches. The traditional MySQL solution for our suite of web applications had hit its ceiling. MongoDB was chosen as the candidate for exploration into NoSQL implementations, and now serves as our go-to data store for rapid application deployment. This talk will detail several of the MongoDB use cases at MMF, from serving 2TB+ of geolocation data, to time-series data for live tracking, to user sessions, app logging, and beyond. Topics will include migration patterns, indexing practices, backend storage choices, and application access patterns, monitoring, and more.
How Thermo Fisher Is Reducing Mass Spectrometry Experiment Times from Days to...MongoDB
Mass spectrometry is the gold standard for determining chemical compositions, with spectrometers often measuring the mass of a compound down to a single electron. This level of granularity produces an enormous amount of hierarchical data that doesn't fit well into rows and columns. In this talk, learn how Thermo Fisher is using MongoDB Atlas on AWS to allow their users to get near real-time insights from mass spectrometry experiments—a process that used to take days. We also share how the underlying database service used by Thermo Fisher was built on AWS.
AWS에서는 Big Data 분석 및 처리를 위해 다양한 Analytics 서비스를 지원합니다. 이 세션에서는 시간이 지날수록 증가하는 데이터 분석 및 처리를 위해 데이터 레이크 카탈로그를 구축하거나 ETL을 위해 사용되는 AWS Glue 내부 구조를 살펴보고 효율적으로 사용할 수 있는 방법들을 소개합니다.
Similar to MongoDB Tokyo - Monitoring and Queueing (20)
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
Search and Society: Reimagining Information Access for Radical FuturesBhaskar Mitra
The field of Information retrieval (IR) is currently undergoing a transformative shift, at least partly due to the emerging applications of generative AI to information access. In this talk, we will deliberate on the sociotechnical implications of generative AI for information access. We will argue that there is both a critical necessity and an exciting opportunity for the IR community to re-center our research agendas on societal needs while dismantling the artificial separation between the work on fairness, accountability, transparency, and ethics in IR and the rest of IR research. Instead of adopting a reactionary strategy of trying to mitigate potential social harms from emerging technologies, the community should aim to proactively set the research agenda for the kinds of systems we should build inspired by diverse explicitly stated sociotechnical imaginaries. The sociotechnical imaginaries that underpin the design and development of information access technologies needs to be explicitly articulated, and we need to develop theories of change in context of these diverse perspectives. Our guiding future imaginaries must be informed by other academic fields, such as democratic theory and critical theory, and should be co-developed with social science scholars, legal scholars, civil rights and social justice activists, and artists, among others.
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
PHP Frameworks: I want to break free (IPC Berlin 2024)Ralf Eggert
In this presentation, we examine the challenges and limitations of relying too heavily on PHP frameworks in web development. We discuss the history of PHP and its frameworks to understand how this dependence has evolved. The focus will be on providing concrete tips and strategies to reduce reliance on these frameworks, based on real-world examples and practical considerations. The goal is to equip developers with the skills and knowledge to create more flexible and future-proof web applications. We'll explore the importance of maintaining autonomy in a rapidly changing tech landscape and how to make informed decisions in PHP development.
This talk is aimed at encouraging a more independent approach to using PHP frameworks, moving towards a more flexible and future-proof approach to PHP development.
4. •Server Density
•+7TB / mth
•+1bn docs / mth
•2-5k inserts/s @ 3ms
We use MongoDB as our primary data store but also as a queueing system. So I’m going to
talk first about how we built the queuing functionality into Mongo and then more generally
about what you need to keep an eye on when monitoring MongoDB in production.
23. Implementation
• Consumers
db.runCommand(
{ findAndModify : <collection>, <options> } )
query: filter (WHERE)
{ query: { inProg: false } }
Specify the query just like any normal query against Mongo. The very first document that
matches this will be returned. Since we’re building a queuing system, we’re using a field
called inProg so we’re asking it to give us documents where this is false - i.e. the processing
of that document isnt in progress.
25. Implementation
• Consumers
db.runCommand(
{ findAndModify : <collection>, <options> } )
sort: selects the first one on multi-match
{ sort: { added: -1 } }
We can also sort e.g. on a timestamp so you can return the oldest documents first, or you
could build a priority system to return more important documents first.
33. It’s a little different,
but not entirely new.
The problem is that MongoDB is fairly new and whilst it’s still just another database running
on a server, there are things that are new and unusual. This means that some old
assumptions are still valid, but others aren’t. You don’t have to approach it as a completely
new thing, but it is a little different. There are disadvantages to this but one advantage is you
can use it for novel tasks, like queuing.
34. Keep it in RAM. Obviously.
www.flickr.com/photos/comedynose/4388430444/
The first and most obvious thing to note is that keeping everything in RAM is faster. But what
does that actually mean and how do you know when something is in RAM?
35. How do you know?
> db.stats()
{
! "collections" : 3,
! "objects" : 379970142,
! "avgObjSize" : 146.4554114991488,
! "dataSize" : 55648683504, 51GB
! "storageSize" : 61795435008,
! "numExtents" : 64,
! "indexes" : 1,
! "indexSize" : 21354514128, 19GB
! "fileSize" : 100816388096,
! "ok" : 1
}
http://www.flickr.com/photos/comedynose/4388430444/
The easiest way is to check the database size. The MongoDB console provides an easy way to
look at the data and index sizes, and the output is provided in bytes.
36. Where should it go?
Should it be in
What?
memory?
Indexes Always
Data If you can
http://www.flickr.com/photos/comedynose/4388430444/
In every case, having something in memory is going to be faster than not. However, that’s not
always feasible if you have massive data sets. Instead, you want to make sure you always
have enough RAM to store all the indexes, which is what the db.stats() output is for. And if
you can, have space for data too. MongoDB is smart about its memory management so it will
keep commonly accessed data in RAM where possible.
37. How you’ll know
1) Slow queries
Thu Oct 14 17:01:11 [conn7410] update sd.apiLog
query: { c: "android/setDeviceToken", a: 1466, u:
"blah", ua: "Server Density Android" } 51926ms
www.flickr.com/photos/tonivc/2283676770/
Although not the only reason, a slow query does indicate insufficient memory. This might be
that you’ve not got the most optimal indexes for a query but if indexes are being used and
it’s still slow, it could be because of a disk i/o bottleneck because the data isn’t in RAM.
Doing an explain on the query will show you what indexes it is using.
38. How you’ll know
2) Timeouts
cursor timed out (20000 ms)
These slow queries will obviously cause a slowdown in your app but they may also cause
timeouts. In the PHP driver a cursor will timeout after 20,000ms by default, although this is
configurable.
39. How you’ll know
3) Disk i/o spikes
www.flickr.com/photos/daddo83/3406962115/
You’ll see write spikes because MongoDB syncs data to disk periodically, but if you’re seeing
read spikes then that can indicate MongoDB is having to read the data files rather than
accessing data from memory. Be careful though because this won’t distinguish between data
and indexes, or even other server activity. Read spikes can also occur even if you have little
or no read activity if the mongod is part of a cluster where the slaves are reading from the
oplog.
40. Watch your storage
1) Pre-alloc
It sounds obvious but our statistics show that people run out disk space suddenly, even
though there is a predictable increase over time. Remember that MongoDB pre-allocates files
before the space is used, so you’ll see your storage being used up in 2GB increments (once
you go past the smaller initial data file sizes).
41. Watch your storage
2) Sharding maxSize
When adding a new shard you can specify the maximum amount of data you want to store on
that shard. This isn’t a hard limit and is instead used as a guide. MongoDB will try to keep the
data balanced across all your shards so that it meets this setting but it may not. MongoDB
doesn’t currently look at actual disk levels and assumes available capacity is the same across
all nodes. As such, it’s advisable that you set this to around 70% of the total available disk
space.
42. Watch your storage
3) Logging
--quiet
db.runCommand("logRotate");
killall -SIGUSR1 mongod
Logging is verbose by default, so you’ll want to use the quiet option to ensure only important
things are output. And assuming you’re logging to a log file, you will want to periodically
rotate it via the MongoDB console so that it doesn’t get too big. You can also do a killall
SIGUSR1 on all your mongod processes from the shell which will cause a log rotation
(because of the SIGUSR1 flag). This is useful if you want to script log rotation or put it into a
cron job.
43. Watch your storage
4) Journaling
david@rs2b ~: ls -alh /mongodbdata/journal/
total 538M
drwxrwxr-x 2 david david 29 Mar 20 16:50 .
drwx------ 4 david david 4.0K Mar 13 09:50 ..
-rw------- 1 david david 538M Mar 20 17:00 j._862
-rw------- 1 david david 88 Mar 20 17:00 lsn
Mongo should rotate the journal files often but you need to remember that they will take up
some space too, and as new files are allocated and old ones deleted, you may see your disk
usage spiking up and down.
44. db.serverStatus()
The server status command provides a lot of different statistics that can help you, like this
map of traffic in central Tokyo.
47. Fri Nov 19 17:24:32 [mongosMain] Listener: accept() returns -1 errno:24 Too many open files
Fri Nov 19 17:24:32 [mongosMain] Listener: accept() returns -1 errno:24 Too many open files
Fri Nov 19 17:24:32 [mongosMain] Listener: accept() returns -1 errno:24 Too many open files
Fri Nov 19 17:24:32 [mongosMain] Listener: accept() returns -1 errno:24 Too many open files
Fri Nov 19 17:24:32 [mongosMain] Listener: accept() returns -1 errno:24 Too many open files
Fri Nov 19 17:24:32 [mongosMain] Listener: accept() returns -1 errno:24 Too many open files
Fri Nov 19 17:24:32 [mongosMain] Listener: accept() returns -1 errno:24 Too many open files
Fri Nov 19 17:24:32 [mongosMain] Listener: accept() returns -1 errno:24 Too many open files
Fri Nov 19 17:24:32 [mongosMain] Listener: accept() returns -1 errno:24 Too many open files
Fri Nov 19 17:24:32 [mongosMain] Listener: accept() returns -1 errno:24 Too many open files
Fri Nov 19 17:24:32 [mongosMain] Listener: accept() returns -1 errno:24 Too many open files
Fri Nov 19 17:24:32 [mongosMain] Listener: accept() returns -1 errno:24 Too many open files
Fri Nov 19 17:24:32 [mongosMain] Listener: accept() returns -1 errno:24 Too many open files
Fri Nov 19 17:24:32 [conn2335] getaddrinfo("rs1b") failed: No address associated with hostname
Fri Nov 19 17:24:32 [conn2335] getaddrinfo("rs1d") failed: No address associated with hostname
Fri Nov 19 17:24:32 [conn2335] getaddrinfo("rs1c") failed: No address associated with hostname
Fri Nov 19 17:24:32 [conn2335] getaddrinfo("rs2b") failed: No address associated with hostname
Fri Nov 19 17:24:32 [conn2335] getaddrinfo("rs2d") failed: No address associated with hostname
Fri Nov 19 17:24:32 [conn2335] getaddrinfo("rs2c") failed: No address associated with hostname
Fri Nov 19 17:24:32 [conn2335] getaddrinfo("rs2a") failed: No address associated with hostname
Fri Nov 19 17:24:32 [conn2268] checkmaster: rs2b:27018 { setName: "set2", ismaster: false, secondary: true, hosts: [ "rs2b:27018", "rs2d:27018", "rs2c:27018", "rs2a:27018" ], arbiters:
[ "rs2arbiter:27018" ], primary: "rs2a:27018", maxBsonObjectSize: 8388608, ok: 1.0 }
MessagingPort say send() errno:9 Bad file descriptor (NONE)
Fri Nov 19 17:24:32 [conn2268] checkmaster: caught exception rs2d:27018 socket exception
Fri Nov 19 17:24:32 [conn2268] MessagingPort say send() errno:9 Bad file descriptor (NONE)
Fri Nov 19 17:24:32 [conn2268] checkmaster: caught exception rs2c:27018 socket exception
Fri Nov 19 17:24:32 [conn2268] MessagingPort say send() errno:9 Bad file descriptor (NONE)
Fri Nov 19 17:24:32 [conn2268] checkmaster: caught exception rs2a:27018 socket exception
Fri Nov 19 17:24:33 [conn2330] getaddrinfo("rs1a") failed: No address associated with hostname
Fri Nov 19 17:24:33 [conn2330] getaddrinfo("rs1b") failed: No address associated with hostname
Fri Nov 19 17:24:33 [conn2330] getaddrinfo("rs1d") failed: No address associated with hostname
Fri Nov 19 17:24:33 [conn2330] getaddrinfo("rs1c") failed: No address associated with hostname
Fri Nov 19 17:24:33 [conn2327] getaddrinfo("rs2b") failed: No address associated with hostname
Fri Nov 19 17:24:33 [conn2327] getaddrinfo("rs2d") failed: No address associated with hostname
Fri Nov 19 17:24:33 [conn2327] getaddrinfo("rs2c") failed: No address associated with hostname
Fri Nov 19 17:24:33 [conn2327] getaddrinfo("rs2a") failed: No address associated with hostname
Fri Nov 19 17:24:33 [conn2126] getaddrinfo("rs2b") failed: No address associated with hostname
Fri Nov 19 17:24:33 [conn2126] getaddrinfo("rs2d") failed: No address associated with hostname
Fri Nov 19 17:24:33 [conn2126] getaddrinfo("rs2c") failed: No address associated with hostname
Fri Nov 19 17:24:33 [conn2126] getaddrinfo("rs2a") failed: No address associated with hostname
Fri Nov 19 17:24:33 [conn2343] getaddrinfo("rs1b") failed: No address associated with hostname
Fri Nov 19 17:24:33 [conn2343] getaddrinfo("rs1d") failed: No address associated with hostname
Fri Nov 19 17:24:33 [conn2343] getaddrinfo("rs1c") failed: No address associated with hostname
Fri Nov 19 17:24:34 [conn2332] getaddrinfo("rs1b") failed: No address associated with hostname
Fri Nov 19 17:24:34 [conn2332] getaddrinfo("rs1d") failed: No address associated with hostname
Fri Nov 19 17:24:34 [conn2332] getaddrinfo("rs1c") failed: No address associated with hostname
Fri Nov 19 17:24:34 [conn2332] getaddrinfo("rs2b") failed: No address associated with hostname
Fri Nov 19 17:24:34 [conn2332] getaddrinfo("rs2d") failed: No address associated with hostname
Fri Nov 19 17:24:34 [conn2332] getaddrinfo("rs2c") failed: No address associated with hostname
Fri Nov 19 17:24:34 [conn2332] getaddrinfo("rs2a") failed: No address associated with hostname
Fri Nov 19 17:24:34 [conn2343] getaddrinfo("rs2d") failed: No address associated with hostname
Fri Nov 19 17:24:34 [conn2343] getaddrinfo("rs2c") failed: No address associated with hostname
Fri Nov 19 17:24:34 [conn2343] getaddrinfo("rs2a") failed: No address associated with hostname
Fri Nov 19 17:24:34 [conn2343] trying reconnect to rs2d:27018
Fri Nov 19 17:24:34 [conn2343] getaddrinfo("rs2d") failed: No address associated with hostname
We’ve recently had this problem and it manifests itself by the logs filling up all available disk
Fri Nov 19 17:24:34 [conn2343] reconnect rs2d:27018 failed
space instantly, and in some cases completely crashing the server.
Fri Nov 19 17:24:34 [conn2343] MessagingPort say send() errno:9 Bad file descriptor (NONE)
Fri Nov 19 17:24:34 [conn2343] trying reconnect to rs2c:27018
Fri Nov 19 17:24:34 [conn2343] getaddrinfo("rs2c") failed: No address associated with hostname
Fri Nov 19 17:24:34 [conn2343] reconnect rs2c:27018 failed
Fri Nov 19 17:24:34 [conn2343] MessagingPort say send() errno:9 Bad file descriptor (NONE)
Fri Nov 19 17:24:34 [conn2343] trying reconnect to rs2a:27018
Fri Nov 19 17:24:34 [conn2343] getaddrinfo("rs2a") failed: No address associated with hostname
Fri Nov 19 17:24:34 [conn2343] reconnect rs2a:27018 failed
Fri Nov 19 17:24:34 [conn2343] MessagingPort say send() errno:9 Bad file descriptor (NONE)
Fri Nov 19 17:24:35 [conn2343] checkmaster: rs2b:27018 { setName: "set2", ismaster: false, secondary: true, hosts: [ "rs2b:27018", "rs2d:27018", "rs2c:27018", "rs2a:27018" ], arbiters:
[ "rs2arbiter:27018" ], primary: "rs2a:27018", maxBsonObjectSize: 8388608, ok: 1.0 }
MessagingPort say send() errno:9 Bad file descriptor (NONE)
48. connPoolStats
> db.runCommand("connPoolStats")
{
! "hosts" : {
! ! "config1:27019" : {
! ! ! "available" : 2,
! ! ! "created" : 6
! ! },
! ! "set1/rs1a:27018,rs1b:27018" : {
! ! ! "available" : 1,
! ! ! "created" : 249
! ! },
...
! },
! "totalAvailable" : 5,
! "totalCreated" : 1002,
! "numDBClientConnection" : 3490,
! "numAScopedConnection" : 3,
}
connPoolStats allows you to see the connection pools that have been set up by a mongos to
connect to different members of the replica set shards. This is useful to correlate against
open file descriptors so you can see if there are suddenly a large number of connections, or if
there are a low number of available connections across your entire cluster.
49. db.serverStatus()
3) Index counters
"indexCounters" : {
! ! "btree" : {
! ! ! "accesses" : 15180175,
! ! ! "hits" : 15178725,
! ! ! "misses" : 1450,
! ! ! "resets" : 0,
! ! ! "missRatio" : 0.00009551932
! ! }
! },
The miss ratio is what you’re looking at here. If you’re seeing a lot of index misses then you
need to look at your queries to see if they’re making optimal use of the indexes you’ve
created. You should consider adding new indexes and seeing if your queries run faster as a
result. You can use the explain syntax to see which indexes queries are hitting, and the total
execution time so you can benchmark them before and after.
50. db.serverStatus()
4) Op counters
www.flickr.com/photos/cosmic_bandita/2395369614/
The op counters - inserts, updates, deletes and queries - are fun to look at, especially if the
numbers are high. But you have to be careful these are not just vanity metrics. There are
some things you can use them for though. If you have a high number of inserts and updates,
i.e. writes, then you may want to look at your fsync time setting. By default this will flush to
disk every 60 seconds but if you’re doing thousands of writes per second you might want to
do this sooner for durability. Of course you can also ensure the write happens from within
the driver. Queries can show whether you need to load off reads to your slaves, which can be
done through the drivers, so that you’re spreading the load across your servers and only
writing to the master. Deletes can also cause concurrency problems if you’re doing a large
number of them and the database keeps having to yield.
51. db.serverStatus()
5) Background flushing
Picture is unrelated! Mmm, ice cream.
The server status output allows you to see the last time data was flushed to disk, and how
long that took. This is useful to see if you’re causing high disk load but also so you can
monitor how often data is being written. Remember that whilst it isn’t synced to disk, you
could experience data loss in the event of a crash or power outage.
52. db.serverStatus()
6) Dur
If you have journalling enabled then serverStatus will also show some stats such as how many
commits have occurred, the amount of data written and how long various operations have
taken. This can be useful for seeing how much overhead durability adds to servers. We’ve
found no noticeable difference when enabling journaling and that’s on servers processing
billions of operations.
53. rs.status()
{
! "_id" : 1,
! "name" : "rs3b:27018",
! "health" : 1,
! "state" : 2,
! "stateStr" : "SECONDARY",
! "uptime" : 1886098,
! "optime" : {
! ! "t" : 1291252178000,
! ! "i" : 13
! },
! "optimeDate" : ISODate("2010-12-02T01:09:38Z"),
"lastHeartbeat" : ISODate("2010-12-02T01:09:38Z")
},
www.ex-astris-scientia.org/inconsistencies/ent_vs_tng.htm (yes it’s a replicator from Star Trek)
If you’re running a replica set then you can use the rs.status() command to get information
about the whole replica set, on any set member. This gives you a few stats about the current
member as well as a full list of every member in the set.
54. rs.status()
1) myState
Value Meaning
0 Starting up (phase 1)
1 Primary
2 Secondary
3 Recovering
4 Fatal error
5 Starting up (phase 2)
6 Unknown state
7 Arbiter
8 Down
en.wikipedia.org/wiki/State_of_matter
The first value is myState which shows you the status of the server you executed the
command on. However, it’s also used in the list of members the command also provides so
you can see the state of any member in the replica set, as that member sees it. This is useful
to understand why members might be down because other members can’t see them.
55. rs.status()
2) Optime
"optimeDate" : ISODate("2010-12-02T01:09:38Z")
www.flickr.com/photos/robbie73/4244846566/
Replica set members who are not master will be secondary, which means they’ll act as a slave
staying up to date with the master. The optimeDate allows you to see whether a member is
behind on the replication sync. The timestamp is the last applied log item so if it’s up to date,
it’ll be very close to the current actual time on the server.
56. rs.status()
3) Heartbeat
"lastHeartbeat" : ISODate("2010-12-02T01:09:38Z")
www.flickr.com/photos/drawblindfaith/3400981091/
The whole idea behind replica sets is that they automate failover in the event of failure
somewhere. This is done by a regular heartbeat that all members send out to all other
members. The status output shows you the last time that particular member was contacted
from the current member. In the event of a network partition it may be that some members
can’t communicate with eachother, and when there is an error you’ll see it in this section too.
57. mongostat
The mongostat tool is included as part of the standard MongoDB download and gives you a
quick, real time snapshot of the current state of your servers.
58. mongostat
1) faults
Picture is unrelated! Snowmobile in Norway.
The faults column shows you the number of Linux page faults per second. This is when
Mongo accesses something that is mapped to the virtual address space but not in physical
memory. i.e. it results in a read from disk. High values here indicate you may not have
enough RAM to store all necessary data and disk accesses may start to become the
bottleneck.
59. mongostat
2) locked
www.flickr.com/photos/bbusschots/4541573665/
The next column is locked, which shows the % of time in a global write lock. When this is
happening no other queries will complete until the lock is given up, or the lock owner yields.
This is indicative of a large, global operation like a remove() or dropping a collection and can
result in slow performance.
60. mongostat
3) index miss
www.flickr.com/photos/gareandkitty/276471187/
Index miss is like we saw in the server status output except instead of an aggregate total,
you can see queries hitting (or missing) the index in real time. This is useful if you’re
debugging specific queries in development or need to track down a server that is performing
badly.
61. mongostat
4) queues
When MongoDB gets too many queries to handle in real time, it queues them up. This is
represented in mongostat by the read and write queue columns. When this starts to increase
you will slowdowns in executing queries as they have to wait to run through the queue. You
can alleviate this by stopping any more queries until the queue has dissipated. Queues will
tend to spike if you’re doing a lot of write operations alongside other write heavy ops, such
as large ranged removes. The second column it the active read and writes.
62. mongostat
5) Diagnostics
The last three columns show the total number of connections per server, the replica set they
belong to and the status of that server. This is useful if you need to quickly see which server
is a master in a replica set.
63. Current operations
db.currentOp();
{
! ! ! "opid" : "shard1:299939199",
! ! ! "active" : true,
! ! ! "lockType" : "write",
! ! ! "waitingForLock" : false,
! ! ! "secs_running" : 15419,
! ! ! "op" : "remove",
! ! ! "ns" : "sd.metrics",
! ! ! "query" : {
! ! ! ! "accId" : 1391,
! ! ! ! "tA" : {
! ! ! ! ! "$lte" : ISODate("2010-11-24T19:53:00Z")
! ! ! ! }
! ! ! },
! ! ! "client" : "10.121.12.228:44426",
! ! ! "desc" : "conn"
! ! },
www.flickr.com/photos/jeffhester/2784666811/
The db.currentOp() function will give you a full list of every operation currently in progress. In
this case there’s a long runnin remove which has been active for over 4 hours. You can see
that it’s targeted at shard 1 and the query is based on an account ID and a timestamp. It’s
part of our retention scripts to remove older metrics data. This is useful because you can
track down long running queries which might be hurting performance, and kill them off using
the opid.