How to List the Users in Linux

List Out the Users in Linux

There may be the situations where you wanted to list out all the users available in Linux. In order to get the user details we have to use few commands as below.

The local user information is placed under /etc/passwd file. Each records in this file is actually a login information. So we will need to read this file. We can use cat to view the users as below.

$ cat   /etc/passwd

If the number of records are more then you can use less as below:

$ less /etc/passwd

Command:

The Output of this command will be as below:

Output:

Now, If you want to display only username then you can use cut command to print only the first column which holds the username as below:

$ cut -d: -f1 /etc/passwd

Output:

There is one another command to display the list of user in linux i.e. getend.This command displays the entries from databases configured in /etc/nsswitch.conf file

You can use this command as below to list the users

$ getent passwd

And to list only the user name you can use this command as below

$ getent passwd | cut -d: -f1

Command:

$ getent passwd | cut -d: -f1

Output:

Thank You!

Vimal

 

How To Find Top Processes By Memory and CPU in Linux

Top Processes Sorted By Memory/CPU Usage

During server health checkup sometimes we try to check the expensive processes running on Linux machine. It is very easy in windows but for Linux you need to type command in order to achieve the same.

Below is the command which we can use. It will not show you the full list. However if you want to see the full list you can remove |head to get full list.

Command:

    @instance-1:~$ ps -eo user,pid,ppid,cmd,%mem,%cpu --sort=-%mem |head 

Output:

Thank You!

Vimal

Log Buffer In Cassandra

Do we have anything  like Log Buffer in memory related to commit log file???

I have started learning Cassandra few months ago and was confused with term "Log buffer" in cassandra. I have gone through several links/documents and they were just telling me about commit log. If you search for Cassandra architecture diagram, it says when a write occurs, Cassandra writes to the memtable(In Memory) and commit log (On DISK).

So, I was more curious to know about log buffer and its functionality. As if it is in memory so what will happen during sudden failure...

I tried one more time to look for the answers and I got this time :)

Summary of this Blog is: Yes, 😊 We have a log buffer in Cassandra which is in OS as Cassandra don’t have any OS like SQL. But the writes are not acknowledged in Cassandra until unless it is written to Disk (It is tunable). 

The setting which control this is: commitlog_sync  (Batch Or periodic) 

By default cassandra support Batch: Which says writes are not acknowledged until fsynced to disk.

Periodic—You can think of this as delayed durability in SQL server. If you are from SQL Background like me.

==============================================================
Below are detailed info:

When we try to read in detail about cassandra commit log, this is where you will get confused..Only I f you are a beginner like me 😊 You will find a term "Log Buffer" and will not get much information about it.  So, The reference to "commit log buffer in memory" is talking about OS buffer cache, not a memory structure in Cassandra.  We can also refer the code regarding same if you know little bit about java programming. There is no separate in-memory structure for the commit log, but rather the mutation is serialized and written to a file-backed buffer.

Cassandra comes with two strategies for managing fsync on the commit log. (Batch and Periodic)

What Cassandra Documentation Says:

Commitlogs are an append only log of all mutations local to a Cassandra node. Any data written to Cassandra will first be written to a commit log before being written to a memtable. This provides durability in the case of unexpected shutdown. On startup, any mutations in the commit log will be applied.

 commitlog_sync: may be either “periodic” or “batch.”

Batch: In batch mode, Cassandra won’t ack writes until the commit log has been fsynced to disk. It will wait “commitlog_sync_batch_window_in_ms” milliseconds between fsyncs. This window should be kept short because the writer threads will be unable to do extra work while waiting. You may need to increase concurrent_writes for the same reason.

commitlog_sync_batch_window_in_ms: Time to wait between 
                                   “batch” fsyncs
Default Value: 2

Periodic: In periodic mode, writes are immediately ack’ed, and the CommitLog is simply synced every “commitlog_sync_period_in_ms” milliseconds.
commitlog_sync_period_in_ms: Time to wait between 
                                 “periodic” fsyncs
    Default Value: 10000


Default Value in cassandra is: batch which says that there will be no data loss in case of sudden failure..

Thank You For Reading this Blog

BCP with MultiSubNetFailover option

Recently, I was stuck with one issue where I was getting a login timeout error when running a BCP command on a SQL 2016 "AlwaysOnAvailabilityGroup" with multisubnet environment.

Our application which was using the JDBC driver to connect to database was running fine.

But when we were trying to connect the database with bcp command it was getting timeout.

I found one workaround at below link which says to use the -l parameter. It will extend the timeout value and will start working. This was taking time as it was resolving the IP's in serial manner.

https://www.sqlservercentral.com/forums/topic/bcp-login-timeout-when-running-on-a-2014-always-on-availability-groups-with-multisubnets

The above option was working fine but was slow. So, I tried some options with bcp command line and found one which worked in my case.

All you have to do is to pass the option ;multisubnetfailover=yes in command line after the listener name as below:

c:\Windows\System32> bcp "SELECT 1" queryout c:\temp_log\bcp12.log -S ListenerName;multisubnetfailover=yes   -T

I changed the connections in my case and started working fine after that.

Please let me know if this works for you :)

Thank You!
Vimal