2016-06-10 21:26:35 +03:00
|
|
|
/*
|
2019-06-20 02:58:25 +03:00
|
|
|
* Copyright (c) Facebook, Inc. and its affiliates.
|
2016-06-10 21:26:35 +03:00
|
|
|
*
|
2019-06-20 02:58:25 +03:00
|
|
|
* This software may be used and distributed according to the terms of the
|
|
|
|
* GNU General Public License version 2.
|
2016-06-10 21:26:35 +03:00
|
|
|
*/
|
2019-10-11 15:26:59 +03:00
|
|
|
|
2019-10-15 23:37:04 +03:00
|
|
|
#include "eden/fs/telemetry/EdenStats.h"
|
2016-06-10 21:26:35 +03:00
|
|
|
|
|
|
|
#include <chrono>
|
2019-04-30 01:44:18 +03:00
|
|
|
#include <memory>
|
2016-06-10 21:26:35 +03:00
|
|
|
|
|
|
|
namespace facebook {
|
|
|
|
namespace eden {
|
|
|
|
|
2020-09-03 01:26:26 +03:00
|
|
|
ChannelThreadStats& EdenStats::getChannelStatsForCurrentThread() {
|
win: when creating a file/directory, create the parents too
Summary:
As opposed to FUSE, ProjectedFS sends notifications for file/directory creation
after the fact, and for directory that means these will be visible on disk before
EdenFS may be aware of it. While EdenFS usually process it quickly, a heavily
multi-threaded application that tries to concurrently create a directory
hierarchy may end up sending notifications to EdenFS in a somewhat out of order
fashion.
Since this should be a very rare occurence, we make this a very slow path by
being optimistic and calling `getInode` first, and then only if that fails, we
aggressively create all the parent directories. During a buck build of ~1k
jobs, this happened only 3 times.
If we fully think this through, this change doesn't fully fix the race, as a
similar race can now happen when a create and remove/rename operations are
concurrent. However, a client performing these operations concurrently is
either aware that this is racy and should handle these properly, or is most
likely buggy. Both of these should significantly reduce the likelyhod of this
happening, thus, I'm leaving this unfixed for now.
To better understand how frequently this happens, I've added a stat counter.
For now, these aren't published to ODS, but this will be tackled later.
Reviewed By: wez
Differential Revision: D22783484
fbshipit-source-id: ea3aafc2f77b65d3967f697f68114921d5909137
2020-07-29 22:15:30 +03:00
|
|
|
return *threadLocalChannelStats_.get();
|
2019-05-30 04:08:03 +03:00
|
|
|
}
|
|
|
|
|
2019-07-01 22:46:52 +03:00
|
|
|
ObjectStoreThreadStats& EdenStats::getObjectStoreStatsForCurrentThread() {
|
|
|
|
return *threadLocalObjectStoreStats_.get();
|
|
|
|
}
|
|
|
|
|
2019-05-30 04:08:03 +03:00
|
|
|
HgBackingStoreThreadStats& EdenStats::getHgBackingStoreStatsForCurrentThread() {
|
|
|
|
return *threadLocalHgBackingStoreStats_.get();
|
|
|
|
}
|
|
|
|
|
|
|
|
HgImporterThreadStats& EdenStats::getHgImporterStatsForCurrentThread() {
|
|
|
|
return *threadLocalHgImporterStats_.get();
|
2019-04-15 06:42:26 +03:00
|
|
|
}
|
|
|
|
|
2019-07-26 09:32:21 +03:00
|
|
|
JournalThreadStats& EdenStats::getJournalStatsForCurrentThread() {
|
|
|
|
return *threadLocalJournalStats_.get();
|
|
|
|
}
|
|
|
|
|
2019-04-15 06:42:26 +03:00
|
|
|
void EdenStats::aggregate() {
|
2021-02-15 03:35:19 +03:00
|
|
|
// Flush the quantile stats since some of our stats are based on that
|
|
|
|
// mechanism. Eventually, every stat will be a quantile stat and we can
|
|
|
|
// remove the rest of the logic from this method.
|
|
|
|
fb303::ServiceData::get()->getQuantileStatMap()->flushAll();
|
|
|
|
|
win: when creating a file/directory, create the parents too
Summary:
As opposed to FUSE, ProjectedFS sends notifications for file/directory creation
after the fact, and for directory that means these will be visible on disk before
EdenFS may be aware of it. While EdenFS usually process it quickly, a heavily
multi-threaded application that tries to concurrently create a directory
hierarchy may end up sending notifications to EdenFS in a somewhat out of order
fashion.
Since this should be a very rare occurence, we make this a very slow path by
being optimistic and calling `getInode` first, and then only if that fails, we
aggressively create all the parent directories. During a buck build of ~1k
jobs, this happened only 3 times.
If we fully think this through, this change doesn't fully fix the race, as a
similar race can now happen when a create and remove/rename operations are
concurrent. However, a client performing these operations concurrently is
either aware that this is racy and should handle these properly, or is most
likely buggy. Both of these should significantly reduce the likelyhod of this
happening, thus, I'm leaving this unfixed for now.
To better understand how frequently this happens, I've added a stat counter.
For now, these aren't published to ODS, but this will be tackled later.
Reviewed By: wez
Differential Revision: D22783484
fbshipit-source-id: ea3aafc2f77b65d3967f697f68114921d5909137
2020-07-29 22:15:30 +03:00
|
|
|
for (auto& stats : threadLocalChannelStats_.accessAllThreads()) {
|
2019-05-30 04:08:03 +03:00
|
|
|
stats.aggregate();
|
|
|
|
}
|
2019-07-01 22:46:52 +03:00
|
|
|
for (auto& stats : threadLocalObjectStoreStats_.accessAllThreads()) {
|
|
|
|
stats.aggregate();
|
|
|
|
}
|
2019-05-30 04:08:03 +03:00
|
|
|
for (auto& stats : threadLocalHgBackingStoreStats_.accessAllThreads()) {
|
|
|
|
stats.aggregate();
|
|
|
|
}
|
|
|
|
for (auto& stats : threadLocalHgImporterStats_.accessAllThreads()) {
|
2019-04-15 06:42:26 +03:00
|
|
|
stats.aggregate();
|
|
|
|
}
|
2019-07-26 09:32:21 +03:00
|
|
|
for (auto& stats : threadLocalJournalStats_.accessAllThreads()) {
|
|
|
|
stats.aggregate();
|
|
|
|
}
|
2019-04-15 06:42:26 +03:00
|
|
|
}
|
|
|
|
|
2019-05-30 04:08:03 +03:00
|
|
|
std::shared_ptr<HgImporterThreadStats> getSharedHgImporterStatsForCurrentThread(
|
2019-04-30 01:44:18 +03:00
|
|
|
std::shared_ptr<EdenStats> stats) {
|
2019-05-30 04:08:03 +03:00
|
|
|
return std::shared_ptr<HgImporterThreadStats>(
|
|
|
|
stats, &stats->getHgImporterStatsForCurrentThread());
|
2019-04-30 01:44:18 +03:00
|
|
|
}
|
|
|
|
|
2019-05-30 04:08:03 +03:00
|
|
|
EdenThreadStatsBase::EdenThreadStatsBase() {}
|
2016-06-10 21:26:35 +03:00
|
|
|
|
2021-02-15 03:35:19 +03:00
|
|
|
EdenThreadStatsBase::Stat EdenThreadStatsBase::createStat(
|
2019-04-15 06:42:25 +03:00
|
|
|
const std::string& name) {
|
2021-02-15 03:35:19 +03:00
|
|
|
return Stat{
|
2021-01-10 21:03:53 +03:00
|
|
|
name,
|
2021-02-15 03:35:19 +03:00
|
|
|
fb303::ExportTypeConsts::kSumCountAvgRate,
|
|
|
|
fb303::QuantileConsts::kP1_P10_P50_P90_P99,
|
|
|
|
fb303::SlidingWindowPeriodConsts::kOneMinTenMinHour,
|
|
|
|
};
|
2017-03-31 21:23:02 +03:00
|
|
|
}
|
|
|
|
|
2019-05-30 04:08:03 +03:00
|
|
|
EdenThreadStatsBase::Timeseries EdenThreadStatsBase::createTimeseries(
|
2019-04-15 06:42:25 +03:00
|
|
|
const std::string& name) {
|
2019-04-11 05:55:31 +03:00
|
|
|
auto timeseries = Timeseries{this, name};
|
2019-07-25 07:04:08 +03:00
|
|
|
timeseries.exportStat(fb303::COUNT);
|
|
|
|
timeseries.exportStat(fb303::PERCENT);
|
2019-04-11 05:55:31 +03:00
|
|
|
return timeseries;
|
|
|
|
}
|
|
|
|
|
2020-09-03 01:26:26 +03:00
|
|
|
void ChannelThreadStats::recordLatency(
|
2021-02-15 03:35:19 +03:00
|
|
|
StatPtr item,
|
2020-09-03 01:26:26 +03:00
|
|
|
std::chrono::microseconds elapsed) {
|
2017-03-31 21:23:02 +03:00
|
|
|
(this->*item).addValue(elapsed.count());
|
|
|
|
}
|
2018-03-20 03:01:15 +03:00
|
|
|
|
2017-11-04 01:58:04 +03:00
|
|
|
} // namespace eden
|
|
|
|
} // namespace facebook
|